On Tue, Feb 16, 2021 at 4:15 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > 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. Got it. I didn't realize this before. Thanks. > > > 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
