On Mon 28-01-19 06:28:16, Tejun Heo wrote: > Hello, Michal. > > On Mon, Jan 28, 2019 at 01:51:51PM +0100, Michal Hocko wrote: > > > For example, a workload manager watching over a subtree for a job with > > > nested memory limits set by the job itself. It wants to take action > > > (reporting and possibly other remediative actions) when something goes > > > wrong in the delegated subtree but isn't involved in how the subtree > > > is configured inside. > > > > Yes, I understand this part, but it is not clear to me, _how_ to report > > anything sensible without knowing _what_ has caused the event. You can > > walk the cgroup hierarchy and compare cached results with new ones but > > this is a) racy and b) clumsy. > > All .events files generate aggregated stateful notifications. For > anyone to do anything, they'd have to remember the previous state to > identify what actually happened. Being hierarchical, it'd of course > need to walk down when an event triggers. And how do you do that in a raceless fashion? > > > That sure is an option for use cases like above but it has the > > > downside of carrying over the confusing interface into the indefinite > > > future. > > > > I actually believe that this is not such a big deal. For one thing the > > current events are actually helpful to watch the reclaim/setup behavior. > > Sure, it isn't something critical. It's just confusing and I think > it'd be better to improve. > > > I do not really think you can go back. You cannot simply change semantic > > back and forth because you just break new users. > > > > Really, I do not see the semantic changing after more than 3 years of > > production ready interface. If you really believe we need a hierarchical > > notification mechanism for the reclaim activity then add a new one. > > I don't see it as black and white as you do. Let's agree to disagree. > I'll ack the patch and note the disagreement. Considering the justification behhind this change I really do not see other option than nack this change. There is simply no _strong_ reason to change the behavior. Even if the current behavior is confusing, the documentation can be improved to be more specific. If there is a strong demand for hierarchical reporting then add a new interface. But I have to say that I would consider such a reporting clumsy at best. -- Michal Hocko SUSE Labs
