Messages in this thread | | | Date | Tue, 9 Mar 1999 12:04:23 -0500 (EST) | From | Chuck Lever <> | Subject | buffer cache growth |
| |
i've been investigating the buffer cache growth problem, reports of slowness when manipulating large files, and D-state processes. i think i've found an important problem (which may have already been discussed here).
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/
| |