Hello, Michal. On Wed, Aug 07, 2013 at 03:26:13PM +0200, Michal Hocko wrote: > I would rather see it not changed unless it really is a big win in the > cgroup core. So far I do not see anything like that (just look at > __cgroup_from_dentry which needs to be exported to allow for the move). The end goal is cleaning up cftype so that it becomes a thin wrapper around seq_file and I'd really like to keep the interface minimal so that it's difficult to misunderstand. > You reduce the amount of code in cgroup.c, alright, but the code > doesn't go away really. It just moves out of your sight and moves the > same burden on somebody else without providing a new generic interface. If the implementation details are all that you're objecting, I'll be happy to restructure it. I just didn't pay too much attention to it because I considered it to be mostly deprecated. I don't think it'll be too much work and strongly think it'll be worth the effort. Our code base is extremely nasty is and I'll try to get any ounce of cleanup I can get. > If somebody needs a notification interface (and there is no one available > right now) then you cannot prevent from such a pointless work anyway... I'm gonna add one for freezer state transitions. It'll be simple "this file changed" thing and will probably apply that to at least oom and vmpressure. I'm relatively confident that it's gonna be pretty simple and that's gonna be the cgroup event mechanism. > cgroup_event_* don't sound memcg specific at all. They are playing with > cgroup dentry reference counting and do a generic functionality which > memcg doesn't need to know about. Sure, I'll try to clean it up so that it doesn't meddle with cgroup internals directly. > I wouldn't object to having non-cgroup internals playing variant. I just > do not think it makes sense to invest time to something that should go > away long term. I suppose it's priority thing. To me, cleaning up cgroup core API is quite important and I'd be happy to sink time and effort into it and it's not like we can drop the event thing in a release cycle or two. We'd have to carry it for years, so I think the effort is justified. 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>