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 ? 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 ? Thanks, Vinayak -- 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>
