Linux v2.5.54

So finally they did it ...

But mmap(NULL, ...) is not yet supported, this is really sad.

And arch/i386/Kconfig and Documentation/vm/hugetlbpage.txt still document the sys_alloc_hugepages()/sys_free_hugepages() syscalls.

A simple program that doesnt know at all how the memory is layed out by kernel/glibc can not easily get some 4Mo pages in a single syscall. sys_alloc_hugepage() was very convenient for that.

Another problem :

if you mount hugetlbfs in /huge, then create a file /huge/BIG of size 4Mo, then use :

dd if=/huge/BIG of=/dev/null

the dd process hangs on 'D' state : the read() syscall just hang forever.

Thanks

Bill, this appears to be a matter of implementing a suitable ->get_unmapped_area() within hugetlbfs?

OK.

Well. One would expect userspace library functions to emerge. The glibc people take patches.

erk. Thanks.

@@ -79,6 +79,7 @@ static int hugetlbfs_file_mmap(struct fi
  */
 static int hugetlbfs_readpage(struct file *file, struct page * page)
 {
+	unlock_page(page);
 	return -EINVAL;
 }

At the time of hugetlbfs' integration, it was desirable to be minimalistic and the additional logic for placement had no clear motivation, as both privilege and great self-awareness were assumed of the applications using hugetlbfs. Since then, it's become apparent that this placement logic is a requirement for userspace support.

Apologies in advance for great tardiness; however, I'll send in patches implementing in-kernel automatic hugetlb vma placement within 36 hours.

Documentation updates are also essential, they will also follow shortly, in tandem with the automatic vma placement.

Ulrich Drepper has already accepted a glibc patch integrating the SHM_HUGETLB flag into glibc. dada1, I'm hopeful your distribution will provide you with an upgrade path to a glibc version implementing it soon, or that you'll otherwise be able to upgrade to a cvs glibc version.