Re: Fw: Linux v2.5.54

From: William Lee Irwin III (wli@holomorphy.com)
Date: Fri Jan 03 2003 - 04:55:41 EST


dada1 wrote:
>> So finally they did it ...
>> But mmap(NULL, ...) is not yet supported, this is really sad.

On Fri, Jan 03, 2003 at 01:26:31AM -0800, Andrew Morton wrote:
> Bill, this appears to be a matter of implementing a suitable
> ->get_unmapped_area() within hugetlbfs?

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.

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

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

dada1 wrote:
>> 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.

On Fri, Jan 03, 2003 at 01:26:31AM -0800, Andrew Morton wrote:
> Well. One would expect userspace library functions to emerge. The
> glibc people take patches.

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.

dada1 wrote:
>> 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.

On Fri, Jan 03, 2003 at 01:26:31AM -0800, Andrew Morton wrote:
> 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;
> }

This fix is trivially correct; thanks for finding and addressing it.
Linus, please apply.

Thanks for the testing, bugreports, and fixes!

Thanks,
Bill
-
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:21 EST