Prev: pcrypt: sysfs interface
Next: [PATCH] compal-laptop/fujitsu-laptop/msi-laptop: make dmi_check_cb to return 1 instead of 0
From: Andi Kleen on 2 Jul 2010 05:10
On Fri, Jul 02, 2010 at 02:47:22PM +0900, Naoya Horiguchi wrote:
> We can't use existing hugepage allocation functions to allocate hugepage
> for page migration, because page migration can happen asynchronously with
> the running processes and page migration users should call the allocation
> function with physical addresses (not virtual addresses) as arguments.

I looked through this patch and didn't see anything bad. Some more
eyes familiar with hugepages would be good though.

Since there are now so many different allocation functions some
comments on when they should be used may be useful too

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 5 Jul 2010 05:30
On Mon, Jul 05, 2010 at 05:46:29PM +0900, Naoya Horiguchi wrote:
> On Fri, Jul 02, 2010 at 11:08:54AM +0200, Andi Kleen wrote:
> > On Fri, Jul 02, 2010 at 02:47:22PM +0900, Naoya Horiguchi wrote:
> > > We can't use existing hugepage allocation functions to allocate hugepage
> > > for page migration, because page migration can happen asynchronously with
> > > the running processes and page migration users should call the allocation
> > > function with physical addresses (not virtual addresses) as arguments.
> >
> > I looked through this patch and didn't see anything bad. Some more
> > eyes familiar with hugepages would be good though.
>
> Yes.
>
> > Since there are now so many different allocation functions some
> > comments on when they should be used may be useful too
>
> OK. How about this?
>
> +/*
> + * This allocation function is useful in the context where vma is irrelevant.
> + * E.g. soft-offlining uses this function because it only cares physical
> + * address of error page.
> + */

Looks good thanks.

> +struct page *alloc_huge_page_node(struct hstate *h, int nid)
> +{
>
> BTW, I don't like this function name very much.
> Since the most significant difference of this function to alloc_huge_page()
> is lack of vma argument, so I'm going to change the name to
> alloc_huge_page_no_vma_node() in the next version if it is no problem.
>
> Or, since the postfix like "_no_vma" is verbose, I think it might be
> a good idea to rename present alloc_huge_page() to alloc_huge_page_vma().
> Is this worthwhile?

Yes, in a separate patch

-Andi

--
ak(a)linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: pcrypt: sysfs interface
Next: [PATCH] compal-laptop/fujitsu-laptop/msi-laptop: make dmi_check_cb to return 1 instead of 0