RE: hugetlb demand paging patch part [2/3]

Chen, Kenneth W
2004-04-16T02:58:07Z

>>>> David Gibson wrote on Thursday, April 15, 2004 7:35 PM
> > Yes, killing follow_hugetlb_page() is safe because follow_page() takes
> > care of hugetlb page. See 2nd patch posted earlier in
> > hugetlb_demanding_generic.patch
>
> Yes, I looked at it already. But what I'm asking about is applying
> this patch *without* (or before) going to demand paging.
>
> Index: working-2.6/mm/memory.c
> =================================> --- working-2.6.orig/mm/memory.c 2004-04-13 11:42:42.000000000 +1000
> +++ working-2.6/mm/memory.c 2004-04-16 11:46:31.935870496 +1000
> @@ -766,16 +766,13 @@
> || !(flags & vma->vm_flags))
> return i ? : -EFAULT;
>
> - if (is_vm_hugetlb_page(vma)) {
> - i = follow_hugetlb_page(mm, vma, pages, vmas,
> - &start, &len, i);
> - continue;
> - }
> spin_lock(&mm->page_table_lock);
> do {
> struct page *map;
> int lookup_write = write;
> while (!(map = follow_page(mm, start, lookup_write))) {
> + /* hugepages should always be prefaulted */
> + BUG_ON(is_vm_hugetlb_page(vma));
> /*
> * Shortcut for anonymous pages. We don't want
> * to force the creation of pages tables for
>
> Yes, I looked at it already. But what I'm asking about is applying
> this patch *without* (or before) going to demand paging.

In that case, yes, it is not absolutely required. But we do special
optimization for follow_hugetlb_pages() in the prefaulting implementation,
at least for ia64 arch. It give a sizable gain on db benchmark.

- Ken