Re: [PATCH v3] mm: make faultaround produce old ptes

[Michal Hocko <mhocko@kernel.org>]

On Wed 24-01-18 17:39:44, Vinayak Menon wrote:
> On 1/24/2018 4:41 PM, Michal Hocko wrote:
> > On Wed 24-01-18 16:13:06, Vinayak Menon wrote:
> >> On 1/24/2018 3:08 PM, Michal Hocko wrote:
> > [...]
> >>> Try to be more realistic. We have way too many sysctls. Some of them are
> >>> really implementation specific and then it is not really trivial to get
> >>> rid of them because people tend to (think they) depend on them. This is
> >>> a user interface like any others and we do not add them without a due
> >>> scrutiny. Moreover we do have an interface to suppress the effect of the
> >>> faultaround. Instead you are trying to add another tunable for something
> >>> that we can live without altogether. See my point?
> >> I agree on the sysctl part. But why should we disable faultaround and
> >> not find a way to make it useful ?
> > I didn't say that. Please read what I've written. I really hate your new
> > sysctl, because that is not a solution. If you can find a different one
> > than disabling it then go ahead. But do not try to put burden to users
> > because they know what to set. Because they won't.
> 
> What about an expert level config option which is by default disabled ?

so we have way too many sysctls and it is hard for users to decide what
to do and now you are suggesting a config option instead? How come this
makes any sense?

> Whether to consider faultaround ptes as old or young is dependent on
> architectural details that can't be gathered at runtime by reading
> some system registers. This needs to be figured out by experiments,
> just like how a value for watermark_scale_factor is arrived at. So the
> user, in this case an engineer expert in this area decides whether the
> option can be enabled or not in the build.
> I agree that it need not be a sysctl, but what is the problem that
> you see in making it a expert level config ? How is it a burden to a
> non-expert user ?

Our config space is immense. Adding more on top will not put a relief.
Just imagine that you get a bug report about a strange reclaim behavior.
Now you have a one more aspect to consider.

Seriously, if a heuristic fails on somebody then just make it more
conservative. Maybe it is time to sit down and rethink how the fault
around should be implemented. No shortcuts and fancy tunables to paper
over those problems.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>