[lkml]   [2005]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] New iovec support & VFS changes
    Badari Pulavarty wrote:
    > I was trying to add support for preadv()/pwritev() for threaded
    > databases. Currently the patch is in -mm tree.
    > rc5/2.6.15-rc5-mm3/broken-out/support-for-preadv-pwritev.patch
    > This needs a new set of system calls. Ulrich Drepper pointed out
    > that, instead of adding a system call for the limited functionality
    > it provides, why not we add new iovec interface as follows (offset-per-
    > segment) which provides greater functionality & flexibility.
    > +struct niovec
    > +{
    > + void __user *iov_base;
    > + __kernel_size_t iov_len;
    > + __kernel_loff_t iov_off; /* NEW */
    > +};

    For a database, it's also helpful to know when an operation is going
    to block on I/O (i.e. because the data isn't cached, or write buffers
    full) and if that's going to happen, move it to another thread, or
    move other operations to another thread. This allows a program to
    continue to work on other things concurrently with I/O more
    effectively than thread pool guesswork.

    So if you add these new syscalls, it would be helpful to add a "flags"
    argument to each of them, and define one flag: "don't block on I/O".
    When the flag is set, the syscalls should do as much reading or
    writing as they can without blocking, and then return the count, or

    (FreeBSD's sendfile() has an SF_NODISKIO flag which means this, and it
    is used in exactly that way: so a program can move the sendfile() to
    another thread iff that is necessary to avoid blocking the program.)

    There's also a case for making these into async I/O operations.
    However, if there is any possibility of async I/O blocking a task for
    a long time (which there is with Linux async I/O apparently), that is
    not half as useful as a flag to stop I/O when it would block, and let
    the program decide what to do.

    I mention this precisely because it's relevant to I/O performance of
    databases and similar programs, and therefore a reason to have a
    "flags" argument to these new syscalls, even if no flags are defined
    at first.

    -- Jamie
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-12-20 18:02    [W:0.023 / U:9.568 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site