the problem is that try_to_free_buffers(), which shrinks the buffer cache,
removes buffers arbitrarily rather than removing least recently used
buffers. this means that shrinking the buffer cache is dangerous and
should be done only as a last resort. this is as it should be. i don't
think try_to_free_buffers() is broken -- removing a page from the buffer
cache is sometimes necessary, but hard to do without disturbing the order
of the cache's LRU lists.
however in recent kernels, the buffer cache has been allowed to grow
without bounds, with the reasoning that the VM system will self-tune the
buffer cache to the correct size. cool idea, except that "tuning the
buffer cache down" is lots more performance-degrading than "tuning the
buffer cache up" helps performance. if the buffer cache grows quickly,
shrink_mmap() will steal pages back just as quickly when VM load is heavy.
in other words, stealing pages from the buffer cache should be a
significantly more rare occurrence.
i've been working on a solution to this that involves two changes:
1. make the buffer cache grow slowly. this adds "hysteresis" to the
dynamics of the VM self-tuning, and prevents the buffer cache from quickly
interfering with a heavy VM and I/O program, and makes it less likely that
shrink_mmap() will find it necessary to steal pages from the buffer cache.
2. change shrink_mmap() to use try_to_free_buffers() only as a very last
resort. stealing random pages from the buffer cache is highly
performance-degrading, and should only be done in an absolute emergency,
not in the course of normal system activity.
i'm still tuning the buffer cache growth rate, and i've added a bunch of
instrumentation (event counters for eventual use with sar). i can post a
patch if anyone is interested; it's against 2.2.2, but can be against
2.2.3.
- 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/