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.
.
