[openib-general] [PATCH] huge pages support
Roland Dreier
rdreier at cisco.com
Thu Aug 17 09:06:36 PDT 2006
My first reaction on reading this is that it looks like we need some
more help from mm/ to make this cleaner.
> + for (j = 0; j < umem->page_size / PAGE_SIZE; ++j)
> + put_page(chunk->page_list[i].page);
This just looks really bad... you're assuming that calling put_page()
on a different page than the one get_user_pages() gave you is OK.
Does that actually work? (I don't remember the details of how hugetlb
pages work)
> + if (hpage == -1)
> + hpage = is_vm_hugetlb_page(vma);
> + else
> + if (hpage != is_vm_hugetlb_page(vma))
> + return -ENOMEM;
Users aren't allowed to register regions that span both hugetlb and
non-hugetlb pages?? Why not?
> + if (!(PAGE_SIZE / (sizeof (struct page *) << shift_diff))) {
shift_diff is used here...
> + ret = -ENOMEM;
> + goto exit_up;
> + }
> +
> + page_size = 1 << page_shift;
> + page_mask = ~(page_size - 1);
> + shift_diff = page_shift - PAGE_SHIFT;
and set down here... don't you get a warning about "is used uninitialized"?
Also, if someone tries to register a hugetlb region and a regular page
isn't big enough to hold all the pointers, then they just lose?? This
would be a real problem if/when GB pages are implemented on amd64 --
there would be no way to register such a region.
Basically this patch seems to be trying to undo what follow_hugetlb_pages()
does to create normal pages for the pieces of a hugetlb page. It
seems like it would be better to have a new function like get_user_pages()
that returned its result in a struct scatterlist so that it could give
back huge pages directly.
- R.
More information about the general
mailing list