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


    On Wed, 28 Jul 1999, Stephen C. Tweedie wrote:

    > > 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.
    >

    I just profiled the 2.3.11 kernel and around 37% of the time was spend in
    file_read_actor. By looking at the function I discovered that this
    function is responsible for copying data from the kernel to the user
    space.

    Here the basic performance of this function:
    data transfered: 1.8 GB
    total execution time of the function: 23 seconds
    ---------------------------------------------------
    throughput per second: 78 MB/sec

    This means that the Linux memory copy function used for copying
    disk data achieves a memory bandwidth of approximately 156 MB/sec
    on a system with a 66 MHz system bus.

    This seems to be rather low and optimizations like the use of MMX (for
    Celeron/Pentium II) or SIMD (for Pentium III) instructions could
    increase memory throughput.

    In addition to that and maybe more promising is the possibility to
    map the page cache straight into the users address space and use copy on
    write if the user modifies the read buffer. (this of course works only
    if the readbuffer is aligned on a 4K boundary and the whole page is read
    in)

    I also profiled the mmapped code and found no such bottlenecks. The CPU
    was mostly idle. Unfortunately a lock in the kernel serializes a
    significant part of the mmap operation therefore leading to a slower
    overall execution time (see my previous postings).

    Here is the list of problems that I found:
    a) serialization of mmap
    b) the memory to memory copy operation from the kernel to
    the user address space takes up a signifcant amount of time
    during read operations


    -Gerald




    -
    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:4.962 / U:0.620 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site