> 1) The kernel copies data many times before it ends up in user
> space.
Err, not AIUI. The block device reads the data from the device into
bh->b_data. This is one copy, if the device doesn't do DMA.
If the request ultimately came from the page cache (as all file data reads
should / do), then bh->b_data will have been initialised to point to part of
the appropriate page in the page cache. If this was a bog-standard read() call,
the data then gets copied to user space.
So that's one or two copies, depending on whether you count reading from the
device as a copy.
> In other words, for read-only access it should not be necessary to
> touch the data read in if the user process is written carefully
> (i.e., reads page-aligned data into a page-aligned buffer).
It isn't necessary, if you've mmap()d it. If you've just read() it, there's
one copy to user space. IIRC there was a discussion about the whole "zero
copy" issue, I think the outcome was that this single copy to user space
was not significant performance-wise, anyway.
> After observing the above problem, I then started experimenting with
> mmap/mlock in the hope that mmap would give me better performance than
> simple read/write commands.
I'll have to look at this a bit more before I comment..
-- "House Plants are for ornamental use only and not for consumption" Notice in Sainsbury's Supermarket, London - Daily Mail- 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/