Messages in this thread | | | Date | Mon, 22 Mar 1999 13:58:01 -0500 (EST) | From | Chuck Lever <> | Subject | Re: [patch] fix for buffer hash leakage |
| |
On Sat, 20 Mar 1999, Linus Torvalds wrote: > However, it is certainly true that the old bforget() was a piece of crap > too. Here's my current one that looks "obviously correct" - can people who > saw the performance problems with the original version please test this > one out?
i've tested this patch under the same environment as i developed my own, and this patch appears to correct the problem as well as mine. buffer cache grows to about 93M then stays fixed there. block reads remain at a low rate during the benchmark, and the CPU is fully utilized.
i've also been running with it on my laptop all weekend, and it appears stable across a variety of applications including ApplixWare, Navigator, kernel builds, mpg123 (of course!), and benchmark runs.
> /* > * bforget() is like brelse(), except it puts the buffer on the > * free list if it can.. We can NOT free the buffer if: > * - there are other users of it > * - it is locked and thus can have active IO > */ > void __bforget(struct buffer_head * buf) > { > if (buf->b_count != 1 || buffer_locked(buf)) { > __brelse(buf); > return; > } > remove_from_queues(buf); > put_last_free(buf); > } > > Can anybody see any downsides with this patch? Note that the likelihood of > the if-statement triggering is pretty low, so I don't think performance > should be any different from Andreas patch, but the above looks safe and > "feels" right to me. I certainly know that I would have been extremely > nervous to release a real kernel with the previous patch posted.
looks OK to me.
- 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/
| |