[lkml]   [2002]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: fadvise syscall?
    Anton Altaparmakov wrote:

    > We don't need fadvise IMHO. That is what open(2) is for. The streaming
    > request you are asking for is just a normal open(2). It will do read
    > ahead which is perfect for streaming (of data size << RAM size in its
    > current form).
    > When you want large data streaming, i.e. you start getting worried
    > about memory pressure, then you want open(2) + O_DIRECT. No caching
    > done. Perfect for large data streams and we have that already. I agree
    > that you may want some form of asynchronous read ahead with passed
    > pages being dropped from the cache but that could be just a open(2) +
    > O_SEQUENTIAL (doesn't exist yet).
    > All of what you are asking for exists in Windows and all the semantics
    > are implemented through a very powerful open(2) equivalent. I don't
    > see why we shouldn't do the same. It makes more sense to me than
    > inventing yet another system call...

    I disagree, and here's the main reasons:

    * fadvise(2) usefulness extends past open(2). It may be useful to call
    it at various points during runtime.

    * I think putting hints in open(2) is the wrong direction to go. Hints
    have a potential to be very flexible. open(2) O_xxx bits are not to be
    squandered lightly, while I see a lot more value in being a little more
    loose and free with the bit assignment for an "fadvise mask" (just a
    list of hint bits). IMO it should be easier to introduce and retire
    hints, far easier than O_xxx flags.


    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:25    [W:0.022 / U:9.364 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site