Fw: Linux v2.5.54

Fw: Linux v2.5.54

[dada1]

>   o remove hugetlb syscalls

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

Re: Fw: Linux v2.5.54

[Andrew Morton]

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;
 }

Re: Fw: Linux v2.5.54

[William Lee Irwin III]

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