• Shaohua Li's avatar
    readahead: fix pipeline break caused by block plug · 3deaa719
    Shaohua Li authored
    Herbert Poetzl reported a performance regression since 2.6.39.  The test
    is a simple dd read, but with big block size.  The reason is:
    
    T1: ra (A, A+128k), (A+128k, A+256k)
    T2: lock_page for page A, submit the 256k
    T3: hit page A+128K, ra (A+256k, A+384). the range isn't submitted
    because of plug and there isn't any lock_page till we hit page A+256k
    because all pages from A to A+256k is in memory
    T4: hit page A+256k, ra (A+384, A+ 512). Because of plug, the range isn't
    submitted again.
    T5: lock_page A+256k, so (A+256k, A+512k) will be submitted. The task is
    waitting for (A+256k, A+512k) finish.
    
    There is no request to disk in T3 and T4, so readahead pipeline breaks.
    
    We really don't need block plug for generic_file_aio_read() for buffered
    I/O.  The readahead already has plug and has fine grained control when I/O
    should be submitted.  Deleting plug for buffered I/O fixes the regression.
    
    One side effect is plug makes the request size 256k, the size is 128k
    without it.  This is because default ra size is 128k and not a reason we
    need plug here.
    
    Vivek said:
    
    : We submit some readahead IO to device request queue but because of nested
    : plug, queue never gets unplugged.  When read logic reaches a page which is
    : not in page cache, it waits for page to be read from the disk
    : (lock_page_killable()) and that time we flush the plug list.
    :
    : So effectively read ahead logic is kind of broken in parts because of
    : nested plugging.  Removing top level plug (generic_file_aio_read()) for
    : buffered reads, will allow unplugging queue earlier for readahead.
    Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
    Signed-off-by: default avatarWu Fengguang <fengguang.wu@intel.com>
    Reported-by: default avatarHerbert Poetzl <herbert@13thfloor.at>
    Tested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    3deaa719
filemap.c 69.5 KB