On Tue, Jul 3, 2018 at 11:47 AM, Janne Johansson <icepic...@gmail.com> wrote: > https://www.tedunangst.com/flak/post/2Q-buffer-cache-algorithm
Thanks. If I'm reading this correctly upon access (read or write), an action is performed depending on what queue a buffer is in: - none: Take a buffer from the tail of the cold queue and insert it at the front of the hot queue. - hot: Keep it there, but move to the front. - cold: Move it to the front of the warm queue. - warm: Keep it there, but move to the front. If a buffer reaches the tail of a queue it moves on like this: hot -> cold cold -> (delete) warm -> cold Based on this understanding, let me describe my (failed) attempt to remove a file from cache. First, let's use 90%: $ doas sysctl kern.bufcachepercent kern.bufcachepercent=90 My machine has 16GB of RAM, but the end of the blog post says something about himem, so maybe this means only 0.9*4GB=3.6GB are used. Now let's create a new file t1, of size 512MB: $ dd bs=1m count=512 if=/dev/zero of=t1 536870912 bytes transferred in 3.458 secs (155210354 bytes/sec) t1 should be in the hot queue now. It can be read at 2GB/s (way faster than disk), so at least we can be sure it is in *some* queue: $ dd bs=1m if=t1 of=/dev/null 536870912 bytes transferred in 0.263 secs (2036532935 bytes/sec) Now let's fill the hot and cold queues with something else: $ dd bs=1m count=16384 if=/dev/zero of=t2 17179869184 bytes transferred in 57.210 secs (300290968 bytes/sec) This should have moved t1 first from the warm to the cold queue and then removed it from the cold queue. But strangely it can still be read at 2GB/s: $ dd bs=1m if=t1 of=/dev/null 536870912 bytes transferred in 0.251 secs (2135681199 bytes/sec) Why is this? How come t1 is still in the cache? (Disclaimer: I've omitted the boring 'records' stats output by dd everywhere.)
