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.
OK.
> 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 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/
This archive was generated by hypermail 2b29 : Tue Jan 07 2003 - 22:00:20 EST