Messages in this thread | | | Date | Thu, 25 Mar 1999 16:00:33 -0500 (EST) | From | Chuck Lever <> | Subject | Re: Linux-2.2.4 testpatch.. |
| |
On Thu, 25 Mar 1999, Linus Torvalds wrote: > > Basically, the only real case I can imagine where this actually > > could result in serious problems is: > > > 1. write a large file that fills much of your memory because > > you're not doing anything else. > > 2. remove the file. > > 3. start applications that do _not_ do any writes to the > > filesystem, but use lots of memory in other ways..
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/
| |