lkml.org 
[lkml]   [2000]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: an experiment in pipe bandwidth improvement
    On Sun, Jan 09, 2000 at 07:32:30PM -0800, Zack Weinberg wrote:
    > I attempted to improve the bandwidth of a pipe by enlarging the kernelside
    > buffer if a writer offers more data than there's room. Currently a pipe
    > write is broken up into one-page chunks. The theory was that this would
    > reduce the number of context switches and system calls, and therefore improve
    > performance.
    >
    > The results are quite surprising: bandwidth is reduced by about 100 MB/sec.

    Quick summary from the rest of this thread: it sounds like the reason
    this is slower is due to killing the CPUs L1 cache as well as the memory
    allocation being relatively slow. That makes sense.

    Without looking at the linux pipe code first (a sin, I know), does it
    always copy the data twice for pipes? I recall that in FreeBSD 2.2.x it
    does something similar to this: The pipe code will "simply" <evil_grin>
    remap the page to the reader's target buffer if it is properly aligned
    (actually, it would have to map it as the kernel pipe buffer first;
    remapping it into the reader only when it actually calls read). The copy
    on write bit should be set in the writer's page table; we don't want
    this to act like shared memory, just minimize the number of large copies.

    Presumably (hopefully) some benchmarking was done on the freebsd code
    to determine at what size copy it becomes useful to do or not do this.
    Fiddling with page tables is very expensive but could be cheaper than
    copying 4k of data twice (into a kernel pipe buffer, and again out the
    other side). On the otherhand, this would significantly increases the
    complexity of the pipe code.

    just curious
    Greg
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:0.036 / U:90.628 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site