lkml.org 
[lkml]   [2006]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/5] mm: tracking dirty pages -v11
    On Sat, 24 Jun 2006, Peter Zijlstra wrote:
    >
    > I hope to have addressed all Hugh's latest comments in this version.
    > Its against 2.6.17-mm1, however I wasted most of the day trying to
    > test it on that kernel. But due to various circumstances that failed.

    Looks good - I'm happy that we leave the do_wp_page test reordering
    (to fix up that third order ptrace poke issue) to a subsequent patch,
    it's better separated.

    > So I've tested something like this against something 2.6.17'ish and
    > respun against the -mm lineup.

    Your next (final?) spin should be against Linus' current git tree,
    http://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.17-git10.bz2
    is the latest snapshot patch if you're not using git itself. That will
    suit Andrew better too: he prefers patches against Linus' current tree,
    except when the changes are to work that's only in -mm.

    You ought to respin, because the vma_wants_writenotify mods in mprotect.c
    affect later patches in your series, giving rejects at present. It does
    look _much_ better with Linus' vma_wants_writenotify. I did think of
    asking you for that, but it seemed unfair because I knew you'd want
    to use it in mprotect, and then get in trouble with backing-dev.h:
    which you've solved by #including that now in mm.h - a pity,
    but an unavoidable decision.

    Given the reordering you had to make in mprotect_fixup to get its tests
    working right (a little naughty!), I'd now do away with the "mask"
    variable, and just work directly on "newflags" itself; but up to you.

    > I've taken Hugh's msync changes too, looks a lot better and does indeed
    > fix some boundary cases.

    Thanks for reviewing: please add my
    Signed-off-by: Hugh Dickins <hugh@veritas.com>
    to that msync one.

    In the respin of 1/5 you enquired:
    > Bah Bah Bah, why didn't the page_mkwrite() patch re-protect clean pages?
    > And is it a Bad-Thing (tm) that that can happen now?

    You'll need a reply from David for the definitive answer, but I think
    page_mkwrite is only wanting to know about the _first_ write to the
    page e.g. so that it can allocate space on disk for that page. And
    many (most) calls to page_mkwrite won't be for that first write at
    all, the filesystem already has to work out the irrelevant calls:
    so it's no great problem that you'll be making some more such calls.

    Hugh
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-06-26 17:38    [W:0.026 / U:0.244 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site