On 1/24/2018 5:51 PM, Michal Hocko wrote: > 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? Because by making it a expert level config we are reducing the users exposed to the configuration. >> 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. Not sure if this is a fault around problem, because without the arch workaround to make the ptes young, faultaround works well. But anyway let me see if I can do something to avoid tunables. Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
