Hello, Michal. On Thu, Oct 05, 2017 at 03:14:19PM +0200, Michal Hocko wrote: > Yes and that is why I think a boot time knob would be the most simple > way. It will also open doors for more oom policies in future which I > believe come sooner or later. While boot params are fine for development and debugging, as a user-interface, they aren't great. * The user can't easily confirm whether the config they input is correct and when they get it wrong what's wrong can be pretty mysterious. * While kernel params can be made r/w through /proc, people usually don't expect that and using that can become really confusing because a lot of people use "dmesg|grep" to confirm the boot params and that won't agree with the setting written later. * It can't be scoped. What if we want to choose different policies per delegated subtree? * Boot params aren't the easiest (again, if you're a developer, they're but most aren't developers) to play with and prone to cause deployment issues. * In this case, even worse because it ends up silently ignoring a clearly explicit configuration in an interface file. If the behavior differences we get from group oom code isn't critical (and it doesn't seem to be), I'd greatly prefer just enabling it when cgroup2 is in use. If it absolutely must be opt-in even on cgroup2, we can discuss other ways but I'd really like to see stronger rationales before going that route. Thanks. -- tejun -- 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>
