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

[Kefeng Wang <wangkefeng.wang@huawei.com>]

On 2021/8/19 15:01, Vlastimil Babka wrote:
> 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.
>
>> 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?

This is no clear limit, we do some test, then choose a big limit which 
is tolerated

by our user, and the user could change it dynamically by sysctl interface.

The dynamically growing threshold is great, I am very agree with this patch.

Like Chris said, the option is that we could also add a max limit then 
let's the

user to make a decision according their scenarios, this is just a option.

>
> .
>