[lkml]   [2003]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: Fw: Linux v2.5.54
dada1 wrote:
> > o remove hugetlb syscalls
> So finally they did it ...
> But mmap(NULL, ...) is not yet supported, this is really sad.

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

> 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.

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

> 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.

erk. Thanks.

--- 25/fs/hugetlbfs/inode.c~hugetlbfs_readpage-fix Fri Jan 3 01:04:42 2003
+++ 25-akpm/fs/hugetlbfs/inode.c Fri Jan 3 01:04:49 2003
@@ -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;
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: 2005-03-22 13:32    [W:0.031 / U:1.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site