[lkml]   [2005]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: process creation time increases linearly with shmem

    On Fri, 26 Aug 2005, Hugh Dickins wrote:
    > I see some flaws in the various patches posted, including Rik's.
    > Here's another version - doing it inside copy_page_range, so this
    > kind of vma special-casing is over in mm/ rather than kernel/.

    I like this approach better, but I don't understand your particular
    choice of bits.

    > + * Assume the fork will probably exec: don't waste time copying
    > + * ptes where a page fault will fill them correctly afterwards.
    > + */
    > + == VM_MAYSHARE)
    > + return 0;
    > +
    > if (is_vm_hugetlb_page(vma))
    > return copy_hugetlb_page_range(dst_mm, src_mm, vma);

    First off, if you just did it below the hugetlb check, you'd not need to
    check hugetlb again. And while I understand VM_NONLINEAR and VM_RESERVED,
    can you please comment on why VM_MAYSHARE is so important, and why no
    other information matters.

    Now, VM_MAYSHARE is a sign of the mapping being a shared mapping. Fair
    enough. But afaik, a shared anonymous mapping absolutely needs its page
    tables copied, because those page tables contains either the pointers to
    the shared pages, or the swap entries.

    So I really think you need to verify that it's a file mapping too.

    Also, arguably, there are other cases that may or may not be worth
    worrying about. What about non-shared non-writable file mappings? What
    about private mappings that haven't been COW'ed?

    So I think that in addition to your tests, you should test for
    "vma->vm_file", and you could toy with testing for "vma->anon_vma" being
    NULL (the latter will cause a _lot_ of hits, because any read-only private
    mapping will trigger, but it's a good stress-test and conceptually
    interesting, even if I suspect it will kill any performance gain through
    extra minor faults in the child).

    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: 2009-11-18 23:46    [W:0.022 / U:13.208 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site