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 think the point Chuck was trying to make was not that preserving
buffers was good because of making a pool of quick-allocation free
buffers, but because doing so preserved the *contents* of those
buffers ---- this is because try_to_free_buffers() doesn't take into
account whether the buffers on any particular pages are often
referenced. So if the buffers contain the disk blocks corresponding to
some commonly used executable that just doesn't happen to be in use at
the moment, try_to_free_buffers will evict the page, thus forcing the
disk blocks to be read in from disk the next time they are needed.
While I agree with you that leaving b_coutn as 1 is a really horrible
way of fixing this problem, the real solution which is quite urgently
needed is to put some more smarts into try_to_free_buffers....
- Ted
-
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/