Re: [RFC 2/2] Hugetlb COW

From: Adam Litke (agl_at_us.ibm.com)
Date: 11/07/05

  • Next message: David Stevens: "Re: [PATCH][MCAST]Clear MAF_GSQUERY flag when process MLDv1 general query messages." 
    To: linux-mm@kvack.org
Date:	Mon, 07 Nov 2005 15:47:55 -0600

    On Mon, 2005-11-07 at 15:38 -0600, Adam Litke wrote:
    > [RFC] COW for hugepages
    > (Patch originally from David Gibson <dwg@au1.ibm.com>)
    >
    > This patch implements copy-on-write for hugepages, hence allowing
    > MAP_PRIVATE mappings of hugetlbfs.
    >
    > This is chiefly useful for cases where we want to use hugepages
    > "automatically" - that is to map hugepages without the knowledge of
    > the code in the final application (either via kernel hooks, or with
    > LD_PRELOAD). We can use various heuristics to determine when
    > hugepages might be a good idea, but changing the semantics of
    > anonymous memory from MAP_PRIVATE to MAP_SHARED without the app's
    > knowledge is clearly wrong.

    I forgot to mention in the original post that this patch is currently
    broken on ppc64 due to a problem with update_mmu_cache(). The proper
    fix is understood but backed up behind the powerpc merge activity. 

    -- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
-
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/
  • Next message: David Stevens: "Re: [PATCH][MCAST]Clear MAF_GSQUERY flag when process MLDv1 general query messages."

    Relevant Pages

    • Re: [RFC 2/2] Hugetlb COW
      ... > This is chiefly useful for cases where we want to use hugepages ... I'll go check for architectures where page protections may be encoded ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Hugetlbpages in very large memory machines.......
      ... > One drawback is that the out of memory handling is lot less nicer ... > than it was before - when you run out of hugepages you get SIGBUS ... arbitrary virtual placement. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] [0/6] HUGETLB memory commitment
      ... >> If there was any likelihood that there would be additional memory domains ... > In short I guess if we only are trying to fix the overcommit cross over between the normal and hugetlb, then the first two patches should be basically there. ... - Make normal overcommit logic skip hugepages completely ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] hugepages: fold find_or_alloc_pages into huge_no_page()
      ... Simplify the code by folding ... > this patch. ... Adam Litke - ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: stack dumps, CONFIG_FRAME_POINTER and i386 (was Re: sysrq shows impossible call stack)
      ... Adam Litke wrote: ... I still don't see any code in there to handle the transition from the ... interrupt stack page to the non-interrupt stack page in the 4k-stacks case? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)