[lkml]   [1999]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PFC]: hash instrumentation
On Fri, 9 Apr 1999, Andrea Arcangeli wrote:
> I would also ask to comment about the run_task_queue(&tq_disk) before
> sleep waiting for bdflush() I/O completation. Why we were running run it
> if then we are going to sleep waiting for a daemon that _will_ generate
> I/O and will recall run_task_queue(&tq_disk) before wakeup us again. Chuck
> told me that such removal decreased a bit performances (maybe it's been a
> random variance in the bench timings?). According to me it should change
> nothing. If it was a black magic or it made a sense I would like to hear a
> comment ;). Thanks!!

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))

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: <>
personal: <> or <>

The Linux Scalability project:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.081 / U:4.028 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site