Re: [PATCH] mm, vmscan: guarantee drop_slab_node() termination

[Chris Down <chris@chrisdown.name>]

Vlastimil Babka writes:
>On 8/19/21 4:55 AM, Kefeng Wang wrote:
>>
>> On 2021/8/19 5:48, Chris Down wrote:
>>> Vlastimil Babka writes:
>>>
>>> I think this is a good idea, thanks for bringing it up :-)
>>>
>>> I'm not sure about the bitshift idea, though. It certainly makes sure
>>> that even large, continuous periods of reclaim eventually terminates,
>>> but I find it hard to reason about -- for example, if there's a lot of
>>> parallel activity, that might result in 10 constantly reintroduced
>>> pages, or 1000 pages, and it's not immediately obvious that we should
>>> treat those differently.
>>>
>>> What about using MAX_RECLAIM_RETRIES? There's already precedent for
>>> using it in non-OOM scenarios, like mem_cgroup_handle_over_high.
>
>It's an option, but then (together with fixed threshold) it ignores how
>large the 'freed' value is, as long it's above threshold? Although the
>end result will probably not be much different.

Yeah, but we already draw the line at 10 right now. `freed > 10 && retries < 
MAX_RECLAIM_RETRIES` seems easier to reason about, at least to me, and 
stays closer to the current behaviour while providing a definitive point of 
loop termination.

>> Yes, we meet this issue too, and we add a max loop limit in
>> drop_slab_node() in our kernel, which also could be reconfigured by
>> sysctl ;)
>
>Sysctl sounds like an overkill. How do you tune the limit? Any
>experience with what scenarios need what limit?

sysctls in mm tend to mean we didn't think hard enough about how things should 
work and just punted it to the user :-)

So I agree with you that I'd rather not have a sysctl, and just go the 
MAX_RECLAIM_RETRIES route. After that I'll happily add my Acked-by.