lkml.org 
[lkml]   [1999]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: (disk/cpu) kernel performance problem
    Hi,

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:0.024 / U:61.420 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site