I am currently developing a software that needs fast inter-process and temporary I/O communication (images as well as big hdf5 arrays). The "lifetime" of the data is different and dependent on several things, but in most cases something between seconds to minutes. Only a few files have to be stored longer. None of the data needs to be saved persistently.

Hence, I thought /dev/shm should be the way to go. However, I am struggling to benchmark /dev/shm.

My first attempt was:

sudo dd if=/proc/kcore of=/dev/shm/mem count=1000000

...which shows the following result:

1000000+0 records in
1000000+0 records out
512000000 bytes (512 MB, 488 MiB) copied, 0,661147 s, 774 MB/s

However, when I run dd with the bs flag to specify how many bytes have to be read/written at a time, the result heavily changes:

sudo dd if=/proc/kcore of=/dev/shm/mem bs=$((1024*1024)) count=512

...results in:

512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 0,166003 s, 3,2 GB/s

Why is it so much faster to read/write very big chunks of data (many bytes 512 times) compared to small chunks of data a lot of times (1.000.000 times, like in the first attempt)?

Is it "legit" to benchmark /dev/shm with dd using /proc/kcore as the source? Or is /proc/kcore somehow limiting the benchmark?

I can not exactly tell how much performance I really do need, but I would like to have more than 1 GB/s read & write speed (because the largest amount of data I am reading or writing is 1 GB and I would like to do so in less than a second).

I am mostly storing big arrays (50 MB up to 1 GB) via HDF5.

  • Is your software actually using dd for IPC? – ott-- Oct 2 '16 at 21:28
  • No, not at all. I just thought dd is an intuitive way to benchmark /dev/shm. Does it matter if data is written via dd or over tools? I mainly store big arrays with hdf5. – daniel451 Oct 2 '16 at 21:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.