Re: [External] Re: [PATCH v15 4/8] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page
From: Michal Hocko
Date: Tue Feb 16 2021 - 03:17:59 EST
On Tue 16-02-21 12:34:41, Muchun Song wrote:
> On Tue, Feb 16, 2021 at 3:39 AM Michal Hocko <mhocko@xxxxxxxx> wrote:
[...]
> > > Using GFP_KERNEL will also use the current task cpuset to allocate
> > > memory. Do we have an interface to ignore current task cpuset?If not,
> > > WQ may be the only option and it also will not limit the context of
> > > put_page. Right?
> >
> > Well, GFP_KERNEL is constrained to the task cpuset only if the said
> > cpuset is hardwalled IIRC. But I do not see why this is a problem.
>
> I mean that if there are more than one node in the system,
> but the current task cpuset only allows one node.
How would that cpuset get a huge pages from a node which is not part of
the cpuset? Well, that would be possible if the cpuset was dynamic but I
am not sure that such a configuration would be very sensible along with
hardwall setup.
> If current
> node has no memory and other nodes have enough memory.
> We can fail to allocate vmemmap pages. But actually it is
> suitable to allocate vmemmap pages from other nodes.
> Right?
Falling back to a different node would be very suboptimal because then
you would have vmemmap back by remote pages. We do not want that.
--
Michal Hocko
SUSE Labs