[lkml]   [1998]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PATCH: Raw device IO for 2.1.131
    > Quite frankly, nobody has EVER given me a reason that makes any kind of
    > sense at all for supporting raw devices in any other way than we already
    > do.

    Imagine a "media server". It has lots of streams sitting on
    disk, many of length >2GB. The user wants some subset of these
    streams to be played, and there is a scheduler that worries
    about when to pull stuff from the disk. The scheduler is aware
    of the timing requirements of the various streams (in a way that
    say OS readahead cannot be). An accurate upper bound on I/O
    completion time is essential, so the streams have large granularity
    to control fragmentation and seeks.

    The actual data is of *no interest* to the CPU. The data
    arrives in main memory only because it needs to be rearranged
    in time and pulled back out to the I/O bus. But what happens
    because of the obligatory copy? Time is wasted, cycles are wasted,
    L1 and L2 caches get toasted, OS buffer cache gets toasted (though
    you mention you'd support facilities to avoid that last).

    With a fast disk array it's easy to make this wastage dominate
    the CPU. You remark that this is an evil oddity; I'm not sure
    I agree. Fast I/O buses are nice. I'd *like* to be I/O bound,
    but it's not in the cards with vanilla Linux because the CPU is
    forced to be involved, to no benefit that I can see.

    Peter Monta
    Imedia Corp.

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

     \ /
      Last update: 2005-03-22 13:46    [W:0.020 / U:6.792 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site