[LSF/MM ATTEND, TOPIC] memcg topics and user defined oom policies

[Michal Hocko <mhocko@suse.cz>]

Hi,
I would like to attend LSF/MM this year. I am mostly interested in the
MM track.

I would like to discuss memcg lowlimit reclaim as a replacement for soft
limit reclaim which should be deprecated and dropped eventually. The
patches have been sent without any feedback yet. We have discussed this
at the Kernel Summit in Edinburgh and had a general agreement on the
topic so I hope this will settle down before the conference already but
there might be some details to talk about in person.

There are some long term plans for memcg like dirty pages throttling
which haven't moved for quite some time (we almost have dirty page
tracking which is a good step forward but still a long way to go).
Another long term item is ~0% cost with memcg enabled but not in use
(aka no groups existing apart from the root).
There were some attempts to get rid of page_cgroup descriptors. We are
at 16B (64b) currently which is not bad but maybe we can do better.
Kamezawa was working on this but he was busy with other project last
year.
Overall simplification/cleanup of the code is also long due as well.

David was proposing memory reserves for memcg userspace OOM handlers.
I found the idea interesting at first but I am getting more and more
skeptical about fully supporting oom handling from within under-oom
group usecase. Google is using this setup and we should discuss what is
the best approach longterm because the same thing can be achieved by a
proper memcg hierarchy as well.

While we are at memcg OOM it seems that we cannot find an easy consensus
on when is the line when the userspace should be notified about OOM [1].

I would also like to continue discussing user defined OOM policies.
The last attempt to resurrect the discussion [2] ended up without any
strong conclusion but there seem to be some opposition against direct
handling of the global OOM from userspace as being too subtle and
dangerous. Also using memcg interface doesn't seem to be welcome warmly.
This leaves us with either loadable modules approach or a generic filter
mechanism which haven't been discussed that much. Or something else?
I hope we can move forward finally.

But I am interested in other mm related discussions as well.

---
[1] - https://lkml.org/lkml/2013/11/14/586
[2] - https://lkml.org/lkml/2013/11/19/191
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>