1

I'm writing an application where disk performance is interesting. I previously used an older, mechanical disk and used the technique in this thread to clear the cache before measuring performance:

// Clear cache for benchmarking                                               
sync();    
std::ofstream ofs("/proc/sys/vm/drop_caches");
ofs << "3" << std::endl;
ofs.close();

That worked well and gave me expected results - a measured disk sequential read speed of ~100 MB/s when clearing the cache, many times higher when cache was left alone.

The other day I installed an SSD disk, mounted under /media/. After a fresh computer restart, the first couple of measurements are as expected (around 300 MB/s) but when the cache kicks in they are obviously much higher.

My problem now is that the lines of code I previously used have no effect since moving the application to the SSD. Does that cache behave in a different way, maybe? Anything I need to do differently to clear it? The only thing that works now is a computer restart.

Community
  • 1
  • 1
Victor Sand
  • 2,270
  • 1
  • 14
  • 32
  • 1
    To the person who downvoted this: Please leave a comment and point out why so that I can fix it. – Victor Sand Aug 21 '13 at 16:00
  • That's weird, those disks should behave identically, as the cache is in a higher layer of the OS... could it be something else, like read cache ON the SSD (note: I'm not even sure they have one...)? – Karoly Horvath Aug 21 '13 at 16:03
  • @KarolyHorvath: Could you elaborate on the read cache idea? I am a newbie on most of these things. – Victor Sand Aug 21 '13 at 16:06
  • http://superuser.com/questions/309613/do-solid-state-disks-ssds-have-a-buffer-cache ... it should only matter if you don't read much. If you read 100s of megabytes, the first couple of mbs of stored content shouldn't make much difference. – Karoly Horvath Aug 21 '13 at 16:09

1 Answers1

0

You don't say just what you were doing and whether anything else was somehow working with that data too. You can only evict unused data from the cache with drop_caches - if for some reason the data is required to be kept (e.g. because it's dirty and needs to be written back) it won't be evictable. From the kernel documentation for drop_caches:

This is a non-destructive operation and will not free any dirty objects. To increase the number of objects freed by this operation, the user may run sync prior to writing to /proc/sys/vm/drop_caches. This will minimize the number of dirty objects on the system and create more candidates to be dropped.

Anon
  • 6,306
  • 2
  • 38
  • 56