Messages in this thread | | | From | Joonsoo Kim <> | Date | Wed, 10 Jun 2020 12:07:17 +0900 | Subject | Re: [PATCH v2 03/12] mm/hugetlb: introduce alloc_control structure to simplify migration target allocation APIs |
| |
2020년 6월 9일 (화) 오후 10:24, Michal Hocko <mhocko@kernel.org>님이 작성: > > On Wed 27-05-20 15:44:54, Joonsoo Kim wrote: > > From: Joonsoo Kim <iamjoonsoo.kim@lge.com> > > > > Currently, page allocation functions for migration requires some arguments. > > More worse, in the following patch, more argument will be needed to unify > > the similar functions. To simplify them, in this patch, unified data > > structure that controls allocation behaviour is introduced. > > > > For clean-up, function declarations are re-ordered. > > This is really hard to review without having a clear picture of the > resulting code so bear with me. I can see some reasons why allocation > callbacks might benefit from a agragated argument but you seem to touch > the internal hugetlb dequeue_huge_page_vma which shouldn't really need > that. I wouldn't mind much but I remember the hugetlb allocation > functions layering is quite complex for hugetlb specific reasons (see > 0c397daea1d4 ("mm, hugetlb: further simplify hugetlb allocation API") > for more background). > > Is there any reason why the agregated argument cannot be limited only to > migration callbacks. That would be alloc_huge_page_node, alloc_huge_page_nodemask > and alloc_huge_page_vma.
I did it since it's simple for me, but, yes, it's not good to touch the internal functions.
Anyway, Vlastimil already suggested not to introduce alloc_control for any hugetlb functions. I will try it on the next version so the next version would not have alloc_control in any hugetlb functions.
Thanks.
| |