Messages in this thread | | | Date | Fri, 3 Jan 2003 01:55:41 -0800 | From | William Lee Irwin III <> | Subject | Re: 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/
| |