lkml.org 
[lkml]   [2003]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fw: Linux v2.5.54
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/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.056 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site