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

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

[Michal Hocko]

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>

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

[David Rientjes]

On Wed, 8 Jan 2014, Michal Hocko wrote:

> 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.
> 

Google is interested in this topic and has been the main motivation for 
userspace oom handlers; we would like to attend for this discussion.

David Rientjes <rientjes@google.com>
Tim Hockin <thockin@google.com>, systems software, senior staff
Kamil Yurtsever <kyurtsever@google.com>, systems software

Thanks.

--
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>

Re: [Lsf-pc] [LSF/MM ATTEND, TOPIC] memcg topics and user defined oom policies

[James Bottomley]

On Fri, 2014-01-10 at 13:23 -0800, David Rientjes wrote:
> On Wed, 8 Jan 2014, Michal Hocko wrote:
> 
> > 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.
> > 
> 
> Google is interested in this topic and has been the main motivation for 
> userspace oom handlers; we would like to attend for this discussion.
> 
> David Rientjes <rientjes@google.com>
> Tim Hockin <thockin@google.com>, systems software, senior staff
> Kamil Yurtsever <kyurtsever@google.com>, systems software

OK, so please don't do this.  Please send in Topic/attend requests as
per the CFP.  Doing this gives us no way to judge the merits of the
request and, administratively, it gets lost because the way I populate
the attendance request table is to filter on the topic/attend requests
and then fold the threads up to the head.

Please send in one separate topic/attend email authored by the person
who wants to attend.

Thanks,

James


--
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>