[lkml]   [2010]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: readahead on directories
    Phillip Susi wrote:
    > On 4/20/2010 8:44 PM, Jamie Lokier wrote:
    > > readahead() doesn't make much sense on a directory - the offset and
    > > size aren't meaningful.
    > >
    > > But does plain opendir/readdir/closedir solve the problem?
    > No, since those are synchronous. I want to have readahead() queue up
    > reading the entire directory in the background to avoid blocking, and
    > get the queue filled with a bunch of requests that can be merged into
    > larger segments before being dispatched to the hardware.

    Asynchronous is available: Use clone or pthreads.

    More broadly: One of the ways to better I/O sorting is to make sure
    you've got enough things in parallel that the I/O queue is never
    empty, so what you issue has time to get sorted before it reaches the
    head of the queue for dispatch. On the other hand, not so many things
    in parallel that the queues fill up and throttle. Unfortunately it
    only works if things aren't serialised by kernel locks - but there's been
    a lot of work on lockless this and that in the kernel, which may help.

    Back to your problem: You need a bunch of scattered block requests to
    be queued and sorted sanely, and readdir doesn't do that, and even
    waits for each block before issuing the next request.

    Or does it?

    A quick skim of fs/{ext3,ext4}/dir.c finds a call to
    page_cache_sync_readahead. Doesn't that do any reading ahead? :-)

    > I don't actually care to have the contents of the
    > directories returned, so readdir() does more than I need in that
    > respect, and also it performs a blocking read of one disk block at a
    > time, which is horribly slow with a cold cache.

    I/O is the probably the biggest cost, so it's more important to get
    the I/O pattern you want than worrying about return values you'll discard.

    If readdir() calls are slowed by lots of calls and libc, consider
    using the getdirentries system call directly.

    If not, fs/ext4/namei.c:ext4_dir_inode_operations points to
    ext4_fiemap. So you may have luck calling FIEMAP or FIBMAP on the
    directory, and then reading blocks using the block device. I'm not
    sure if the cache loaded via the block device (when mounted) will then
    be used for directory lookups.

    -- Jamie

     \ /
      Last update: 2010-04-21 18:15    [W:0.020 / U:54.140 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site