>From: Brian Swetland <swetland@be.com>
[ ... regarding BeOS streaming movie players ... ]
>I don't believe the extractors read incredibly large chunks. However,
>reads greater than 64K will bypass the block cache on BeOS (generally
>causing scatter-gather DMA directly to userspace memory) and BFS tends
>to be pretty good about keeping files reasonable contiguous.
Sure, but the weak link here is disk seeking, and there's no way to
remove that from the system. If you don't interleave the data for each
track (which is, I believe, untenable for HDR), you are required to
seek between the files as you read ahead for each one. The overhead of
kernel->user space copying is completely trivial compared to the seek
time. So, as nice as the DMA-to-userspace approach sounds, I don't
think it will actually help much in this case.
Note also that as Dan Hollis pointed out to me in a private message
that even using "contiguous blocks" on the disk doesn't offer
predictable seek performance because of the complexity of modern hard
drives. Does BFS go so far as to build a "map" of the physical layout
of the drive so that it can allocate "really contiguous" blocks ?
--p
-
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/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:07 EST