[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.024 / U:13.880 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site