lkml.org 
[lkml]   [2004]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: anon-vma (and now filebacked-mappings too) mprotect vma merging [Re: 2.6.5-rc2-aa vma merging]
    On Sat, 3 Apr 2004, Andrea Arcangeli wrote:
    > On Fri, Apr 02, 2004 at 12:34:29PM +0100, Hugh Dickins wrote:
    > > Sorry to be boring, Andrea, but 2.6.5-rc3-aa2 is now out, and you
    > > have still not fixed the vma merging issue: I don't believe you can.
    >
    > here we go with the mprotect merging, try this on top of 2.6.5-rc3-aa2.

    Thank you! It works. You've surprised me again. Forgive me.

    It's a bit erratic, test program below you'd expect to end up with one
    vma of 4 pages at 0x80000000, whereas it ends up with one of 1 and one
    of 3 (where mainline ends up with two of 2); but that's just an
    implementation detail which obviously can be smoothed away later.
    Presumably it should be looking to merge, or propagating anon_vma
    to/from adjacent vma, somewhere else too.

    It does look more complicated than I'd hoped, a lot of that coming from
    the file-backed merging: which I like, but, we could have done it at
    any point over the last couple of years if someone had a need for it.
    Fair enough, you've discovered a need, at the same time that you have
    to attend to vm_pgoff for anons, so it makes sense to do them together.

    Do you realize that you could allocate just a single anon_vma to
    the mm at fork time, for all the pure anon vmas created in it later?
    And then no need for propagating anon_vma from adjacent vma, they'd
    all have the right one already and be mergeable anyway. But I think
    you'll reject that on two grounds: you want to merge the file-backed
    vmas as much as is reasonable, so you need the code anyway for them;
    and you'd prefer your anon_vma lists to be as short as possible, to
    minimize searching at page_referenced/try_to_unmap time.

    Clearly there's a tension between keeping the anon_vma lists short,
    and leaving the vmas mergable: it's natural that we should differ on
    where to strike that balance, having come to it from opposite ends.

    I still prefer my simpler anonmm solution (will post the prio tree
    patch on top of it later this evening), but I don't see any good
    reason now to oppose your anon_vma solution. Let others decide.

    Hugh

    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <sys/mman.h>

    #define PAGE_SIZE 4096
    #define MAP_AREA ((void *) 0x80000000)

    int main(int argc, char *argv[])
    {
    unsigned long pageno = 0;
    unsigned long *ptr;
    char buf[40];

    ptr = mmap(MAP_AREA, 2*PAGE_SIZE, PROT_READ,
    MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, -1, 0);
    if (ptr == MAP_FAILED)
    exit(1);
    ptr = mmap(MAP_AREA + 2*PAGE_SIZE, 2*PAGE_SIZE, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, -1, 0);
    if (ptr == MAP_FAILED)
    exit(1);
    ptr = MAP_AREA;
    while (pageno < 4) {
    if (mprotect(ptr, PAGE_SIZE, PROT_READ|PROT_WRITE) == -1)
    exit(1);
    *ptr = pageno++;
    if (mprotect(ptr, PAGE_SIZE, PROT_READ) == -1)
    exit(1);
    ptr += PAGE_SIZE / sizeof(unsigned long);
    }
    sprintf(buf, "cat /proc/%d/maps", getpid());
    system(buf);
    exit(0);
    }

    -
    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: 2005-03-22 14:02    [W:0.021 / U:301.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site