[lkml]   [2010]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Unexpected splice "always copy" behavior observed
    * Steven Rostedt ( wrote:
    > On Wed, 2010-05-19 at 17:33 +0200, Miklos Szeredi wrote:
    > > On Wed, 19 May 2010, Linus Torvalds wrote:
    > > > Btw, since you apparently have a real case - is the "splice to file"
    > > > always just an append? IOW, if I'm not right in assuming that the only
    > > > sane thing people would reasonable care about is "append to a file", then
    > > > holler now.
    > >
    > > Virtual machines might reasonably need this for splicing to a disk
    > > image.
    > This comes down to balancing speed and complexity. Perhaps a copy is
    > fine in this case.
    > I'm concerned about high speed tracing, where we are always just taking
    > pages from the trace ring buffer and appending them to a file or sending
    > them off to the network. The slower this is, the more likely you will
    > lose events.
    > If the "move only on append to file" is easy to implement, I would
    > really like to see that happen. The speed of splicing a disk image for a
    > virtual machine only impacts the patience of the user. The speed of
    > splicing tracing output, impacts how much you can trace without losing
    > events.

    I'm with Steven here. I only care about appending full pages at the end of a
    file. If possible, I'd also like to steal back the pages after waiting for the
    writeback I/O to complete so we can put them back in the ring buffer without
    stressing the page cache and the page allocator needlessly.



    Mathieu Desnoyers
    Operating System Efficiency R&D Consultant
    EfficiOS Inc.

     \ /
      Last update: 2010-05-19 17:59    [W:0.021 / U:160.852 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site