lkml.org 
[lkml]   [2009]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RESEND] [PATCH] readahead:add blk_run_backing_dev
    Date

    sorry for late responce.
    I wonder why I and Wu don't contain Cc list in this thread.


    > Hisashi Hifumi wrote:
    > > At 09:36 09/06/01, Andrew Morton wrote:
    > >> On Fri, 29 May 2009 14:35:55 +0900 Hisashi Hifumi
    > >> <hifumi.hisashi@oss.ntt.co.jp> wrote:
    > >>
    > >>> I added blk_run_backing_dev on page_cache_async_readahead
    > >>> so readahead I/O is unpluged to improve throughput on
    > >>> especially RAID environment.
    > >> I skipped the last version of this because KOSAKI Motohiro
    > >> <kosaki.motohiro@jp.fujitsu.com> said "Please attach blktrace analysis ;)".
    > >>
    > >> I'm not sure why he asked for that, but he's a smart chap and
    > >> presumably had his reasons.
    > >>
    > >> If you think that such an analysis is unneeded, or isn't worth the time
    > >> to generate then please tell us that. But please don't just ignore the
    > >> request!
    > >
    > > Hi Andrew.
    > >
    > > Sorry for this.
    > >
    > > I did not ignore KOSAKI Motohiro's request.
    > > I've got blktrace output for both with and without the patch,
    > > but I just did not clarify the reason for throuput improvement
    > > from this result.
    > >
    > > I do not notice any difference except around unplug behavior by dd.
    > > Comments?
    >
    > Pardon my ignorance on the global issues concerning the patch, but
    > specifically looking at the traces generated by blktrace leads one to
    > also note that the patched version may generate inefficiencies in other
    > places in the kernel by reducing the merging going on. In the unpatched
    > version it looks like (generally) that two incoming bio's are able to be
    > merged to generate a single I/O request. In the patched version -
    > because of the quicker unplug(?) - no such merging is going on. This
    > leads to more work lower in the stack (twice as many I/O operations
    > being managed), perhaps increased interrupts & handling &c. [This may be
    > acceptable if the goal is to decrease latencies on a per-bio basis...]
    >
    > Do you have a place where the raw blktrace data can be retrieved for
    > more in-depth analysis?

    I think your comment is really adequate. In another thread, Wu Fengguang pointed
    out the same issue.
    I and Wu also wait his analysis.

    Thanks.




    \
     
     \ /
      Last update: 2009-06-06 16:39    [W:4.282 / U:0.800 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site