On 2024/8/22 22:35, Yafang Shao wrote:
On Thu, Aug 22, 2024 at 4:04 PM Gao Xiang <hsiangkao@xxxxxxxxxxxxxxxxx> wrote:
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.
If the LOCs in the error handler are a concern, I believe we can
simplify it to a single line: while (!alloc()), which is essentially
what NOFAIL does and is also the reason we want desperate NOFAIL.
A better approach might involve failing after a maximum number of
retries at the call site, for example:
while (try < max_retries && !alloc())
At least that is better than the endless loop in the page allocator.
Funny.
Thanks,
Gao Xiang
