Hi Michal,
On 2024/8/22 15:54, Michal Hocko wrote:
On Thu 22-08-24 15:01:43, Gao Xiang wrote:
In my opinion, I'm not sure how PAGE_ALLOC_COSTLY_ORDER restriction
means for a single shot. Because assume even if you don't consider
a virtual consecutive buffer, people could also do
< PAGE_ALLOC_COSTLY_ORDER allocations multiple times to get almost
the same heavy workload to the whole system. And we also allow
direct/kswap reclaim here.
Quite honestly I do not think that PAGE_ALLOC_COSTLY_ORDER constrain
make sense outside of the page allocator proper. There is no reason why
vmalloc NOFAIL should be constrained by that. Sure it should be
contrained to some value but considering it is just a bunch of PAGE_SIZE
allocation then the limit could be higher. I am not sure where the
practical limit should be but anything that requires more than couple of
MBs seems really excessive.
Yeah, totally agreed, that would make my own life easier, of
course I will not allocate MBs insanely.
I've always trying to kill unnecessary NOFAILs (mostly together
with code cleanups), but if a failure path increases more than
100 LOCs just for rare failure and extreme workloads, I _do_
hope kvmalloc(NOFAIL) could work instead.
And for PAGE_ALLOC_COSTLY_ORDER and NOFAIL at the page allocator level I
would argue that we do not want to provide such a strong guarantee to
anything order > 0. Just use kvmalloc for that purpose. Sure we
practically never fail up to costly order but guaranteeing that is a
different story.
Agreed.
Thanks,
Gao Xiang
