On Mon, 17 Aug 2009, Andi Kleen wrote: > Eric B Munson writes: > > > 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 uses 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. > > > You seem to have forgotten to describe WHY you want this? > > From my guess, this seems to be another step into turning hugetlb.c > into another parallel VM implementation. Instead of basically > developing two parallel VMs wouldn't it be better to unify the two? > > I think extending hugetlb.c forever without ever thinking about > that is not the right approach. > > -Andi > > -- > ak@linux.intel.com -- Speaking for myself only. > This patch is meant to simplify the programming model because presently there is a large chunk of boiler plate code required to create private, hugepage backed mappings. This patch would allow use of huge pages without linking to libhugetlbfs or having hugetblfs mounted. Unification 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 wihtout providing any benefit on these architectures. Eric -- Eric B Munson IBM Linux Technology Center ebmunson@us.ibm.com