Messages in this thread | | | Date | Wed, 24 Mar 1999 23:56:19 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Linux-2.2.4 testpatch.. |
| |
On Thu, 25 Mar 1999, Chuck Lever wrote: > > when i first considered this, i agreed with your reasoning, and thought > that it would be a good change. however, after trying it under load, i > discovered that leaving b_count as 1 for free buffers actually *helps* > performance, and doesn't appear to cause the memory shortage problems you > feared.
Performance optimization is 15% brains, 85% black magic. I could easily imagine that in many conditions, the extra locked-down free buffers improve performance by making a pool of quick-allocation free buffers available, even at the expense of other things.
> i'm genuinely curious to know, btw, what pathological conditions > do you think might cause a catastrophic memory shortage?
I said they were unlikely..
Basically, the only real case I can imagine where this actually could result in serious problems is: - write a large file that fills much of your memory because you're not doing anything else. - remove the file. - start applications that do _not_ do any writes to the filesystem, but use lots of memory other ways..
> the best solution is to figure out how to allow page stealing while not > disturbing the LRU queues in the buffer cache.
Indeed. Leaving the b_count at an elevated number may give you some of that advantage, but it's definitely not something I want to count on for good behaviour..
Linus
- 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/
| |