[lkml]   [2002]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] adding aio_readv/writev
    >>Comments, reasons for not doing async readv/writev directly welcome.

    How about the case for it... See Pages 404-406 [Section 12.7] of
    Richard Steven's ``Advanced Programming in the Unix Environment''
    [aka APUE]. Richard measures almost a factor of 2 difference
    in system time between using vectored I/O and not using it on
    a Sun and on a x86.

    >>- there exists at least one major application class (databases)
    >> that uses vectored I/O heavily and benefits from async I/O.
    >> Hence async vectored I/O is also likely to be useful. Can anyone
    >> else with experience on other OS's comment on this ?

    .... a number of other comments/arguments from other
    .... responces removed to get the meat of the discussion.

    Becareful out there.....

    Large commercial applications such as Oracle DB, IBM's DB2 or
    Netscape Enterprise server for that matter - are very modular in
    their interface to OS because they have to be and have been, ported
    and tuned to run on a number of different OS's and HW architectures.
    When I see some one say something about ``Oracle'' doing X or Y -
    I get a little worried.

    Which version, which port etc... e.g. Oracle's DB running on VMS
    has a different I/O system interface that is different from any of
    it's Unix implementations...... oh yes - was the clustered or
    not... did it have the X package etc...

    The point is that the UNIX implementations of Oracle DB vary
    widely..... This is also true of every >>major<< application package
    I have worked/consulted seen some of the insides (SAP, Informix,
    Netscape, etc...).

    Solaris and Tru64 [and I would expect AIX, HP-UX
    etc... but I only know these two personally] each offer
    a highly parallel I/O, asynchronous (but proprietary) interface.
    Oracle's Sun group (or the old DEC group) exploit the >>private<<
    interfaces -- to make the code work better - they do.

    That may or may not be what you have seen on some ``simple Un*x''
    port - which is a starting point for them - that's not the code
    they ship on the high end revenue systems.

    Oracle/IBM/Netscape etc... do this cause the want to grab customers
    from their competetors (DB2, Informix, etc.)... they invest in
    using the best interfaces available.... if they are available
    AND if they can help them sell more copies of their product.

    So... let's get back to the basic issue....

    We know that vectored/scatter gather I/O can help a number of real
    applications ... Richard demonstrated that. We have some examples
    [like DB2] that have use vectored I/O successfully. We also
    know asynchronous I/O has been demonstrated to be useful and
    know that some commerical folks have used that.

    I'm gather from some of the comments, adding async/vectored
    will make an already complex subsystem, even more so [i.e. not
    a resounding endorsement for sure this is easy].

    So the question is can async vectored I/O be implemented
    to have a positive gain, such as it did within the traditonal one.
    If the complexity is too high and it does not help much...then
    maybe this is a Chimera to leave alone. But.... if it can be
    done with some level of elegance... well.... the past history is
    that the commerical folks have used those features.

    I know this this sounds a little bit like:
    ``if you build it - they will come.''

    But I would say it's more to this point:
    ``if you build it and this new feature shows some real value
    AND the application can exploit it ... in time, they will
    because if they don't their competetors will.''

    Clem Cole
    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-03-22 13:29    [W:0.042 / U:5.368 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site