another common example (besides Riley's) might be:
1. & 2. run "Bonnie" with default 100M test file
3. start "mpg123 -Z"
again, i don't *think* this will cause a catastrophic memory shortage.
from my own experimentation, shrink_mmap() appears to be able to get
memory from other places easily enough, even when the buffer cache is
large. leaving b_count set to one simply limits the number of buffers that
are reclaimable by try_to_free_buffers() in this scenario to buffers that
aren't free but hold data from currently unused blocks.
the reason this isn't so bad is because if the file is large enough, all
of it won't be in the buffer cache anyway. this means that truncating and
unlinking it will cause fewer buffers to be added to the free list.
a good test for this might be adjusting the minimum buffer cache size
upwards to, say, 50% of physical memory; then try the ostensible
pathological behavior.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/citi-netscape/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/