[lkml]   [2011]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Approaches to making io_submit not block
    On Tue, Aug 30, 2011 at 03:54:38PM -0700, Andrew Morton wrote:
    > Also, glibc has userspace for POSIX AIO. A successful kernel-based
    > implementation would result in glibc migrating away from its current
    > implementation. So we should work with the glibc developers on ensuring
    > that the migration can happen.

    Unfortunately the glibc userspace POSIX AIO limits asynchronicity to
    one outstanding request per file descriptor. From aio_misc.c in glibc:

    if (runp != NULL
    && runp->aiocbp->aiocb.aio_fildes == aiocbp->aiocb.aio_fildes)
    /* The current file descriptor is worked on. It makes no sense
    to start another thread since this new thread would fight
    with the running thread for the resources. But we also cannot
    say that the thread processing this desriptor shall immediately
    after finishing the current job process this request if there
    are other threads in the running queue which have a higher
    priority. */

    /* Simply enqueue it after the running one according to the
    priority. */

    I have often wondered if this is actually the case ? I created
    my own glibc with a patches AIO that removed this restriction
    (thus had multiple outstanding threads on a single fd). In testing
    I saw a dramatic increase in performance (2x speedup) but then
    testing with use in actual code (Samba smbd) it made the client
    throughput *worse*. I never got to the bottom of this and so
    didn't submit my fixes to glibc.

    Any ideas if this is still the case ? Or comments on why glibc
    insists on only one outstanding request per fd ? Is this really
    needed for kernel performance ?


     \ /
      Last update: 2011-08-31 01:15    [W:0.020 / U:32.496 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site