On Mon, 26 Jul 1999 11:10:28 -0700 (PDT), Gerald Aigner
<aigner@stanford.edu> said:
> 1) The kernel copies data many times before it ends up in user
> space.
No. For read IO, the data is copied precisely once. The kernel does
DMA directly from disk into the page cache, and then the data is copied
into user space.
> 2) Using mmap doesn't help because it serializes I/O within a single
> process (you can't read simultaneously from two disks).
True, although using threads can help.
> I briefly looked into the kernel and think that most of these 45% of
> execution time is spend in copying the data just read in from buffer
> to buffer until it reaches the user address space (since I don't have
> any kernel hacking experience I couldn't figure out how many buffers
> exactly were involved).
Absolutely not. If you want to find out where the time is being spent,
try "man readprofile". You'll probably find that it's in the IO
request layers and drivers, but not in the caches.
> As far as I understand the simplest and fasted implementation involves
> the following operations:
> ...
> 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).
That's what mmap() does. There is truly no copy involved.
For writes, 2.2 does perform more copies than necessary, but that is
cured in 2.3.
> 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. Unfortunately mmap/mlock made things
> worse.
Is this on 2.0 or 2.2? 2.2 adds extra readahead for sequential mmap
access which allows us to reach disk bandwidth for applications like
grep().
--Stephen
-
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/