there are one or two other places where there are two run_task_queue()'s
instead of one (e.g. sync_old_buffers() ). removing one of those also
causes slowdowns.
> I have also some news about my (2.2.5_arca5-8) VM from people who tried
> it.
>
> Well the code is slower (kernel compile and similar are slower). The fact
> is that taking a better information about the working set is more
> expensive. But people who tried it under swap is been _very_ happy and
> seen a _big_ responsiveness difference/improvement.
>
> But to be sure I am reviewing all my code to make sure that the slowdown
> is really due the lru-handling in every find-page/find-buffer.
i think that's the key. moving this bit of code from getblk() to
find_buffer() is a measureable slowdown, it turns out:
if (buffer_uptodate(bh))
put_last_lru(bh);
i removed it completely (along with put_last_lru() since now no-one uses
it), since these lists are no longer LRU, and found that performance
improves. you might find that taking it out of your kernel will help
performance under light (nonswapping) load.
but this also means that you should be *very* careful where you put your
"touch_buffer(bh)" because you don't want that in a performance path like
find_buffer(). leaving touch_buffer() in bread() and brw_page() might be
enough to keep your new page LRUs accurate. this is probably especially
critical on SMP, since the next and prev pointers are in different cache
lines for both buffer heads and page structs, and both fields get written
into when you re-arrange the LRU list.
also, you might want to consider that there is no longer any need to
insert items into the buffer lists on both ends -- just the front will be
fine, since these are no longer LRU lists. that might simplify the logic
of the list management functions.
- 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/