Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU

Vlastimil Babka
2024-03-12T14:46:34Z

On 3/3/24 23:45, NeilBrown wrote:
> On Sat, 02 Mar 2024, Kent Overstreet wrote:
>>
>> *nod*
>>
>> > I suspect that most places where there is a non-error fallback already
>> > use NORETRY or RETRY_MAYFAIL or similar.
>>
>> NORETRY and RETRY_MAYFAIL actually weren't on my radar, and I don't see
>> _tons_ of uses for either of them - more for NORETRY.
>>
>> My go-to is NOWAIT in this scenario though; my common pattern is "try
>> nonblocking with locks held, then drop locks and retry GFP_KERNEL".
>>
>> > But I agree that changing the meaning of GFP_KERNEL has a potential to
>> > cause problems. I support promoting "GFP_NOFAIL" which should work at
>> > least up to PAGE_ALLOC_COSTLY_ORDER (8 pages).
>>
>> I'd support this change.
>>
>> > I'm unsure how it should be have in PF_MEMALLOC_NOFS and
>> > PF_MEMALLOC_NOIO context. I suspect Dave would tell me it should work in
>> > these contexts, in which case I'm sure it should.
>> >
>> > Maybe we could then deprecate GFP_KERNEL.
>>
>> What do you have in mind?
>
> I have in mind a more explicit statement of how much waiting is
> acceptable.
>
> GFP_NOFAIL - wait indefinitely
> GFP_KILLABLE - wait indefinitely unless fatal signal is pending.
> GFP_RETRY - may retry but deadlock, though unlikely, is possible. So
> don't wait indefinitely. May abort more quickly if fatal
> signal is pending.
> GFP_NO_RETRY - only try things once. This may sleep, but will give up
> fairly quickly. Either deadlock is a significant
> possibility, or alternate strategy is fairly cheap.
> GFP_ATOMIC - don't sleep - same as current.
>
> I don't see how "GFP_KERNEL" fits into that spectrum. The definition of
> "this will try really hard, but might fail and we can't really tell you
> what circumstances it might fail in" isn't fun to work with.

The problem is if we set out to change everything from GFP_KERNEL to one of
the above, it will take many years. So I think it would be better to just
change the semantics of GFP_KERNEL too.

If we change it to remove the "too-small to fail" rule, we might suddenly
introduce crashes in unknown amount of places, so I don't think that's feasible.

But if we change it to effectively mean GFP_NOFAIL (for non-costly
allocations), there should be a manageable number of places to change to a
variant that allows failure. Also if these places are GFP_KERNEL by mistake
today, and should in fact allow failure, they would be already causing
problems today, as the circumstances where too-small-to-fail is violated are
quite rare (IIRC just being an oom victim, so somewhat close to
GFP_KILLABLE). So changing GFP_KERNEL to GFP_NOFAIL should be the lowest
risk (one could argue for GFP_KILLABLE but I'm afraid many places don't
really handle that as they assume the too-small-to-fail without exceptions
and are unaware of the oom victim loophole, and failing on any fatal signal
increases the chances of this happening).

> Thanks,
> NeilBrown
>
>
>>
>> Deprecating GFP_NOFS and GFP_NOIO would be wonderful - those should
>> really just be PF_MEMALLOC_NOFS and PF_MEMALLOC_NOIO, now that we're
>> pushing for memalloc_flags_(save|restore) more.
>>
>> Getting rid of those would be a really nice cleanup beacuse then gfp
>> flags would mostly just be:
>> - the type of memory to allocate (highmem, zeroed, etc.)
>> - how hard to try (don't block at all, block some, block forever)
>>
>
>