lkml.org 
[lkml]   [1998]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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.

Cheers,
Peter Monta pmonta@imedia.com
Imedia Corp.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site