On 11/20/2012 10:23 PM, David Rientjes wrote: > Anton can correct me if I'm wrong, but I certainly don't think this is > where mempressure is headed: I don't think any accounting needs to be done > and, if it is, it's a design issue that should be addressed now rather > than later. I believe notifications should occur on current's mempressure > cgroup depending on its level of reclaim: nobody cares if your memcg has a > limit of 64GB when you only have 32GB of RAM, we'll want the notification. My main concern is that to trigger those notifications, one would have to first determine whether or not the particular group of tasks is under pressure. And to do that, we need to somehow know how much memory we are using, and how much we are reclaiming, etc. On a system-wide level, we have this information. On a grouplevel, this is already accounted by memcg. In fact, the current code already seems to rely on memcg: + vmpressure(sc->target_mem_cgroup, + sc->nr_scanned - nr_scanned, nr_reclaimed); Now, let's start simple: Assume we will have a different cgroup. We want per-group pressure notifications for that group. How would you determine that the specific group is under pressure? -- 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>