Hi, > > Memory notifications are quite irrelevant to partitioning and cgroups. The > use-case is related to user-space handling low memory. Meaning the > functionality should be accurate with specific granularity (e.g. 1 MB) and > time (0.25s is OK) but better to have it as simple and battery-friendly. I > prefer to have pseudo-device-based text API because it is easy to debug and > investigate. It would be nice if it will be possible to use simple scripting > to point what kind of memory on which levels need to be tracked but > private/shared dirty is #1 and memcg cannot handle it. > If that is the case, then fine. The reason I jumped in talking about memcg, is that it was mentioned that at some point we'd like to have those notifications on a per-group basis.
So I'll say it again: if this is always global, there is no reason any cgroup needs to be involved. If this turns out to be per-process, as Anton suggested in a recent e-mail, I don't see any reason to have cgroups involved as well. But if this needs to be extended to be per-cgroup, then past experience shows that we need to be really careful not to start duplicating infrastructure, and creating inter-dependencies like it happened to other groups in the past. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
