linux low IO performance on /dev/ram ?!?

[legacy]

Code: [Select]

dd if=/dev/zero of=/dev/ram0 bs=1k count=4000
4000+0 records in
4000+0 records out
4096000 bytes (3.9MB) copied, 0.736300 seconds, 5.3MB/s

/dev/ram0 is ram, PC133 SDRAM! And the CPU is 266Mhz, how can IO performance on a RAM disk can be so ... slow?

What can be wrong? (there is no bus, no DMA, in the middle) 

[legacy]

linux-4.11

Code: [Select]

~ # cat /proc/cpuinfo
processor       : 0
cpu             : 405GP
clock           : 266.640000MHz
revision        : 1.69 (pvr 4011 0145)
bogomips        : 533.28
timebase        : 266640000
Memory          : 48 MB


[legacy]

(it's a PowerPC 405GP by IBM/AMCC, the core is similar to a PPC603)

[westfw]

Is /dev/ram SUPPOSED to be a high-performance interface?  I would have guessed (without any actual knowledge) a sort of raw access to ramdisk from user space, probably involving multiple context switches and pager remapping for each block (or even for each byte...)  All the higher performance code would be stuck in the higher level drivers.  Sort-of like trying to access a hard drive with a "read sector" API.

[llkiwi2006]

What is the performance like on a tmpfs? /dev/ram isn't used that much anymore. Also, try with a bigger block size, you might be limited by the CPU's performance.

[helius]

Suggest you monitor the process with iostat

[hans]

Well, what figures do you actually expect to get?

I think 5MB/s on so much overhead is actually very respectable. Note that /dev/mem is a character device, so it must go through all the device driver layers, before it can finally commit the write.
If you want faster performance, I suppose you need to escape the user land.

[legacy]

I was expecting 20 Mbyte/sec at least since it's a block of ram pre-allocated in an area that the kernel can't use for anything else.

I am experimenting the same kind of problem with a special block-device I have created recycling the MTD's code. It's a true-ram-disk used to store the rootfs, but it gives 3Mbyte/sec 

[GeorgeOfTheJungle]

IDK, but for comparison, look:

Code: [Select]

pi@xu4:~$ sudo dd if=/dev/zero of=/dev/ram0 bs=1k count=4000
[sudo] password for pi:
4000+0 records in
4000+0 records out
4096000 bytes (4.1 MB) copied, 0.0402256 s, 102 MB/s


Code: [Select]

pi@bananapi:~$ sudo dd if=/dev/zero of=/dev/ram0 bs=1k count=4000
[sudo] password for pi:
4000+0 records in
4000+0 records out
4096000 bytes (4.1 MB) copied, 0.0706718 s, 58.0 MB/s


Code: [Select]

pi@odroidc1:~$ sudo dd if=/dev/zero of=/dev/ram0 bs=1k count=4000
[sudo] password for pi:
4000+0 records in
4000+0 records out
4096000 bytes (4.1 MB) copied, 0.0324672 s, 126 MB/s


Code: [Select]

pi@orangepipc:~$ sudo dd if=/dev/zero of=/dev/ram0 bs=1k count=4000
[sudo] password for pi:
4000+0 records in
4000+0 records out
4096000 bytes (4.1 MB) copied, 0.0309904 s, 132 MB/s


[legacy]

yes, there is something wrong with my kernel!
/dev/ram0 is not /dev/mem, and it' a true block-device!

the problem is WTF is wrong?!?!?

[legacy]

The PPC405GP comes with a Synchronous DRAM (SDRAM) interface operating up to 133MHz
and it's 32-bit interface for non-ECC applications

Can't be so slow!!!

The kernel was (cross-)compiled with  powerpc-unknown-linux-gnu-v4.2.4 ...
I wonder ... if it needs some special "flags", but PPC405GB should be a true-PPC603 core 

[donotdespisethesnake]

Sounds like you've never used software before 

[legacy]

Sounds like you've never used software before 

sure, I a porn-actor 

[legacy]

I have changed the cross-builder's profile  and I am building a new gcc-toolchain with "-m405", that (I hope) should force gcc to be ppc405-optimized 

I am open to better advice! ( I am more an HDL-guy than a linux-guy )

[legacy]

Code: [Select]

mount -t tmpfs /mnt/disk0/ /mnt/disk0/
rm /root/here
uc-walnut-earlyrootfs disk0 # dd if=/dev/zero of=/mnt/disk0/here bs=1k count=5000
5000+0 records in
5000+0 records out
5120000 bytes (4.9MB) copied, 0.530093 seconds, 9.2MB/s

 

[Bruce Abbott]

Code: [Select]

mount -t tmpfs /mnt/disk0/ /mnt/disk0/
rm /root/here
uc-walnut-earlyrootfs disk0 # dd if=/dev/zero of=/mnt/disk0/here bs=1k count=5000
5000+0 records in
5000+0 records out
5120000 bytes (4.9MB) copied, 0.530093 seconds, 9.2MB/s

 

What happens if you increase the block size?

For reference, here are the results for different buffer sizes on my ancient 50MHz Amiga 1200:-

Code: [Select]

Device: ram:
Comment A1200 with Blizzard 1230-50 MKII (50MHz 68030)
Test Intensity: High  Performance Stress: None

      147 Files/s Create
      249 Files/s Open/Close
     1620 Files/s Scan
      279 Files/s Delete

      688 Seek/Read

Buffer Size 512 4096 32768 262144
--------- --------- --------- --------- ---------
Bytes/s Create    582605   1355734   1631826   1672495
Bytes/s Write    828824   4391582   9418787 11012736
Bytes/s Read    837769   4449206   9644387 11302545Faster than a 266MHz PPC with PC133 SDRAM!

[legacy]

What happens if you increase the block size?

tmpfs stays around 9Mbyte/sec
/dev/ram0 stays around 4.5Mbyte/sec

I can't understand why the  PPC405GP's ram controller (built-in) is so slow.

I have re-created the toolchain, and gcc is now using a special flag for the 405GP, but .. it's still slow.

[legacy]

oh, tried kernels from 2.6.22 to 2.6.39, and then the 4.11

there is no difference 

[GeorgeOfTheJungle]

An OrangePi PC is only $15 :-)

[Monkeh]

An OrangePi PC is only $15 :-)

As his name implies, he's allergic to any technology developed in the 21st century.

[legacy]

An OrangePi PC is only $15 :-)

As his name implies, he's allergic to any technology developed in the 21st century.

I have a product based on PowerPC405GP, and I can't change it.

[GeorgeOfTheJungle]

I have a product based on PowerPC405GP, and I can't change it.

Oh ohhh. Good luck then.

[langwadt]

An OrangePi PC is only $15 :-)

As his name implies, he's allergic to any technology developed in the 21st century.

I have a product based on PowerPC405GP, and I can't change it.

tried from a c program?

[nctnico]

I'd look for some kind of rogue (kernel) process or driver eating up all the CPU time.

[legacy]

I'd look for some kind of rogue (kernel) process or driver eating up all the CPU time.

I personally wrote the rootfs, and the bootstrap scripts. Once the kernel is loaded and booted, it loads /sbin/init, that loads sshd, and the bash shell.

you have a bash shell connected to the console (/dev/ttyS0, serial line), and a remote ssh shell.

there is nothing else launched!

which kind of rouge (kernel) process? and how to investigate?