Re: [External] Re: [PATCH v15 4/8] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux