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.
