4 ms·
Nice, that looks very handy especially the analysis of multiple runs. Just today I was playing with /proc/sys/vm/drop_caches, I'd never used it before, it make
by anfractuosity 9y ago
Nice, that looks very handy especially the analysis of multiple runs.
Just today I was playing with /proc/sys/vm/drop_caches, I'd never used it before, it makes a massive difference reading from a spinning disk!
For example to read tens of thousands of files (using 8 processes), it would take me
real 5m33.048s
Then if I ran the command again, without flushing the cache, it'd take:
real 0m6.502s
- mynewtb 9y agoIf something like my .ssh got into disk cache, could another user read that or is it not a kernel or RAM thing?
- anfractuosity 9y agoHmm, that's an interesting question. I'd be surprised if you can get access to the page/disk cache without root privileges though. I'm gonna do some more digging on that. Edit: Maybe Meltdown, lets you access the RAM with that though I guess?
- gtirloni 9y agoThe page cache exists to speed up access and it's transparent to processes. If another user/process tries to access your SSH files directly, it'll go through the traditional file permissions to determine if it has access or not. If the disk block is in the page cache AND access is allowed to that inode, then the kernel will retrieve the page from the cache and give it to the process. To read the whole page cache, you'd need code sitting in kernel space. If something manages to load itself in the kernel space (e.g. kernel module), you have bigger problems to worry about.
- sharkdp 9y agoThank you for the feedback! Yes, having a "cold" or a "warm" disk cache makes a massive difference for I/O-heavy programs. For one of my other programs, I differentiate between "cold-cache" and "warm-cache" benchmarks: https://github.com/sharkdp/fd-benchmarks https://github.com/sharkdp/fd-benchmarks