[lkml]   [2004]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: anon_vma RFC2
    Hi Andrea,

    On Thu, 11 Mar 2004, Andrea Arcangeli wrote:
    > this is the full current status of my anon_vma work. Now fork() and all
    > the other page_add/remove_rmap in memory.c plus the paging routines
    > seems fully covered and I'm now dealing with the vma merging and the
    > anon_vma garbage collection (the latter is easy but I need to track all
    > the kmem_cache_free).

    I'm still making my way through all the relevant mails, and not even
    glanced at your code yet: I hope later today. But to judge by the
    length of your essay on vma merging, it strikes me that you've taken
    a wrong direction in switching from my anon mm to your anon vma.

    Go by vmas and you have tiresome problems as they are split and merged,
    very commonly. Plus you have the overhead of new data structure per vma.
    If your design magicked those problems away somehow, okay, but it seems
    you're finding issues with it: I think you should go back to anon mms.

    Go by mms, and there's only the exceedingly rare (does it ever occur
    outside our testing?) awkward case of tracking pages in a private anon
    vma inherited from parent, when parent or child mremaps it with MAYMOVE.

    Which I reused the pte_chain code for, but it's probably better done
    by conjuring up an imaginary tmpfs object as backing at that point
    (that has its own little cost, since the object lives on at full size
    until all its mappers unmap it, however small the portion they have
    mapped). And the overhead of the new data structre is per mm only.

    I'll get back to reading through the mails now: sorry if I'm about to
    find the arguments against anonmm in my reading. (By the way, several
    times you mention the size of a 2.6 struct page as larger than a 2.4
    struct page: no, thanks to wli and others it's the 2.6 that's smaller.)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:01    [W:0.020 / U:16.504 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site