|From:||Eric B Munson <email@example.com>|
|To:||firstname.lastname@example.org, email@example.com, firstname.lastname@example.org|
|Subject:||[PATCH 0/7] Add pseudo-anonymous huge page mappings V3|
|Date:||Fri, 18 Sep 2009 06:21:46 -0600|
|Cc:||email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Eric B Munson <email@example.com>|
This patch set adds a flag to mmap that allows the user to request a mapping to be backed with huge pages. This mapping will borrow functionality from the huge page shm code to create a file on the kernel internal mount and use it to approximate an anonymous mapping. The MAP_HUGETLB flag is a modifier to MAP_ANONYMOUS and will not work without both flags being preset. A new flag is necessary because there is no other way to hook into huge pages without creating a file on a hugetlbfs mount which wouldn't be MAP_ANONYMOUS. To userspace, this mapping will behave just like an anonymous mapping because the file is not accessible outside of the kernel. This patch set is meant to simplify the programming model, presently there is a large chunk of boiler plate code, contained in libhugetlbfs, required to create private, hugepage backed mappings. This patch set would allow use of hugepages without linking to libhugetlbfs or having hugetblfs mounted. Unification of the VM code would provide these same benefits, but it has been resisted each time that it has been suggested for several reasons: it would break PAGE_SIZE assumptions across the kernel, it makes page-table abstractions really expensive, and it does not provide any benefit on architectures that do not support huge pages, incurring fast path penalties without providing any benefit on these architectures. This verion includes the fixes posted to linux-mm as well as additions to mman.h for the four archtiectures that do not make use of mman-common.h. The addition of the MAP_HUGETLB flag to these four (xtensa, parisc, alpha, and mips) is required because MAP_HUGETLB is used in common vm code. Eric B Munson (7): hugetlbfs: Allow the creation of files suitable for MAP_PRIVATE on the vfs internal mount Add MAP_HUGETLB for mmaping pseudo-anonymous huge page regions Add MAP_HUGETLB example Add MAP_HUGETLB flag to alpha mman.h Add MAP_HUGETLB flag to xtensa mman.h Add MAP_HUGETLB flag to parisc mman.h Add MAP_HUGETLB flag to mips mman.h Documentation/vm/00-INDEX | 2 + Documentation/vm/hugetlbpage.txt | 14 ++++--- Documentation/vm/map_hugetlb.c | 77 +++++++++++++++++++++++++++++++++++++ arch/alpha/include/asm/mman.h | 6 +++ arch/mips/include/asm/mman.h | 6 +++ arch/parisc/include/asm/mman.h | 7 +++ arch/xtensa/include/asm/mman.h | 6 +++ fs/hugetlbfs/inode.c | 13 +++++- include/asm-generic/mman-common.h | 1 + include/linux/hugetlb.h | 19 ++++++++- ipc/shm.c | 2 +- mm/mmap.c | 19 +++++++++ 12 files changed, 160 insertions(+), 12 deletions(-) create mode 100644 Documentation/vm/map_hugetlb.c -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to firstname.lastname@example.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"email@example.com"> firstname.lastname@example.org </a>
Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds