Hello, Michal. On Mon, Aug 05, 2013 at 06:01:07PM +0200, Michal Hocko wrote: > Could you be more specific about what is so "overboard" about this > interface? I am not familiar with internals much, so I cannot judge the > complexity part, but I thought that eventfd was intended for this kind > of kernel->userspace notifications. It's just way over-engineered like many other things in cgroup, most likely misguided by the appearance that cgroup could be delegated and accessed by multiple actors concurrently. The most clear example would be the vmpressure event. When it could have just called fsnotify_modify() unconditionally when the state changes, now it involves parsing, dynamic list of events and so on without actually adding any benefits. For the usage ones, configurability makes some sense but even then just giving it a single array of event points of limited size would be sufficient. It's just way over-done. > So you think that vmpressure, oom notification or thresholds are > an abuse of this interface? What would you consider a reasonable > replacement for those notifications? Or do you think that controller > shouldn't be signaling any conditions to the userspace at all? I don't think the ability to generate events are an abuse, just that the facility itself is way over-engineered. Just generate a file changed event unconditionally for vmpressure and oom and maybe implement configureable cadence or single set of threshold array for threshold events. These are things which can and should be done in a a few tens of lines of code with far simpler interface. There's no need for this obsecenely flexible event infrastructure, which of course leads to things like shared contiguous threshold table without any size limit and allocated with kmalloc(). So, let's please move towards something simple. 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>