Re: PATCH: Raw device IO for 2.1.131
Richard Gooch (rgooch@atnf.csiro.au)
Mon, 14 Dec 1998 12:19:18 +1100
pmonta@halibut.imedia.com writes:
> > 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.
But isn't this where sendfile(2) is used? The input file is your disc
file and the output file is your network socket. The kernel triggers
the DMA from disc to memory (say a skbuf) and then triggers the DMA
from memory to the network interface. No cache pollution at all.
You could even develop this further and have the kernel trigger DMA
from disc to network interface. No need to get memory involved at
all. If we can do it with TV in a window (IIRC there is a direct
PCI->PCI DMA from the video capture card to the display frame buffer),
why can't we do that with your application?
Regards,
Richard....
-
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/