Thread (37 messages) 37 messages, 4 authors, 2021-02-18

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

From: Muchun Song <hidden>
Date: 2021-02-16 09:06:49
Also in: linux-fsdevel, linux-mm, lkml

On Tue, Feb 16, 2021 at 4:15 PM Michal Hocko [off-list ref] wrote:
On Tue 16-02-21 12:34:41, Muchun Song wrote:
quoted
On Tue, Feb 16, 2021 at 3:39 AM Michal Hocko [off-list ref] wrote:
[...]
quoted
quoted
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help