On Mon, Feb 14, 2005 at 01:40:58PM -0800, Andrew Morton wrote: >>> Seems about right. There's also the buffer_heads_over_limit logic in >>> mm/vmscan.c and fs/buffer.c. That logic has a hole in that it requires >>> that there be a highmem shortage before we start to reclaim the lowmem >>> buffer_heads, but it is somewhat helpful.
William Lee Irwin III <[EMAIL PROTECTED]> wrote: >> It would be beneficial to close the hole in that logic. On Mon, Feb 14, 2005 at 02:31:42PM -0800, Andrew Morton wrote: > Really? Who's hurting? Apart from the fact that buffer_head proliferation has been a perennial problem, there's little to go on. By and large 2.6.x production usage is not yet very significant where I can see it, where the "production" usage is largely more stressful on account of very long durations and the variety of unusual situations to which the kernel is subjected. William Lee Irwin III <[EMAIL PROTECTED]> wrote: >> Do you have any >> particularly preferred methods in mind? On Mon, Feb 14, 2005 at 02:31:42PM -0800, Andrew Morton wrote: > None that are particularly elegant. One approach might be to trigger a > highmem zone scan when we hit the limit, and to somehow tell that scan to > only do buffer_head stripping. This is largely what I expected. I'll cook something up depending on what conclusion is made from the above response. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
