[lkml]   [2010]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Unexpected splice "always copy" behavior observed
    On Wed, May 19, 2010 at 02:00:51AM +1000, Nick Piggin wrote:
    > On Tue, May 18, 2010 at 10:56:24AM -0500, Christoph Lameter wrote:
    > > On Wed, 19 May 2010, Nick Piggin wrote:
    > >
    > > > What would be needed is to have filesystem maintainers go through and
    > > > enable it on a case by case basis. It's trivial for tmpfs/ramfs type
    > > > filesystems and I have a patch for those, but I never posted it on.yet.
    > > > Even basic buffer head filesystems IIRC get a little more complex --
    > > > but we may get some milage just out of invalidating the existing
    > > > pagecache rather than getting fancy and trying to move buffers over
    > > > to the new page.
    > >
    > > There is a "migration" address space operation for moving pages. Page
    > > migration requires that in order to be able to move dirty pages. Can
    > > splice use that?
    > Hmm yes I didn't think of that, it probably could.

    It's not the only requirement, of course, just that it could
    potentially reuse some of the code.

    The big difference is that the source page is already dirty, and
    the destination page might not exist, might exist and be partially
    uptodate, not have blocks allocated, might be past i_size, fully
    uptodate, etc.

    So it's more than a matter of just a simple copy to another page
    and taking over exactly the same filesystem state as the old page.

     \ /
      Last update: 2010-05-18 18:15    [W:0.021 / U:68.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site