| Message ID | 20180906054342.25094-1-aneesh.kumar@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC,V2,1/4] mm: Export alloc_migrate_huge_page | expand |
On Thu 06-09-18 11:13:39, Aneesh Kumar K.V wrote:
> We want to use this to support customized huge page migration.
Please be much more specific. Ideally including the user. Btw. why do
you want to skip the hugetlb pools? In other words alloc_huge_page_node*
which are intended to an external use?
On Thu 06-09-18 14:31:11, Michal Hocko wrote: > On Thu 06-09-18 11:13:39, Aneesh Kumar K.V wrote: > > We want to use this to support customized huge page migration. > > Please be much more specific. Ideally including the user. Btw. why do > you want to skip the hugetlb pools? In other words alloc_huge_page_node* > which are intended to an external use? Ups, I have now found http://lkml.kernel.org/r/20180906054342.25094-2-aneesh.kumar@linux.ibm.com which ended up in a different email folder so I have missed it. It would be much better to merge those two to make the user immediately obvious. There is a good reason to keep newly added functions closer to their users.
On 09/06/2018 06:05 PM, Michal Hocko wrote: > On Thu 06-09-18 14:31:11, Michal Hocko wrote: >> On Thu 06-09-18 11:13:39, Aneesh Kumar K.V wrote: >>> We want to use this to support customized huge page migration. >> >> Please be much more specific. Ideally including the user. Btw. why do >> you want to skip the hugetlb pools? In other words alloc_huge_page_node* >> which are intended to an external use? > > Ups, I have now found http://lkml.kernel.org/r/20180906054342.25094-2-aneesh.kumar@linux.ibm.com > which ended up in a different email folder so I have missed it. It would > be much better to merge those two to make the user immediately obvious. > There is a good reason to keep newly added functions closer to their > users. > It is the same series. I will fold the patch 1 and 2. -aneesh
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index c39d9170a8a0..98c9c6dc308c 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -357,6 +357,8 @@ struct page *alloc_huge_page_nodemask(struct hstate *h, int preferred_nid, nodemask_t *nmask); struct page *alloc_huge_page_vma(struct hstate *h, struct vm_area_struct *vma, unsigned long address); +struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask, + int nid, nodemask_t *nmask); int huge_add_to_page_cache(struct page *page, struct address_space *mapping, pgoff_t idx); diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 47566bb0b4b1..88881b3f8628 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1586,8 +1586,8 @@ static struct page *alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask, return page; } -static struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask, - int nid, nodemask_t *nmask) +struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask, + int nid, nodemask_t *nmask) { struct page *page;
We want to use this to support customized huge page migration. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> --- include/linux/hugetlb.h | 2 ++ mm/hugetlb.c | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-)