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 Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux