[ATTEND][LSF/MM TOPIC] the memory controller

[ATTEND][LSF/MM TOPIC] the memory controller

[Lord Glauber Costa of Sealand]

Hi,

I've been working actively over the past year with the memory
controller, in particular its usage to track special bits of interest in
kernel memory land. As this work progress, I'd like to propose and
participate in the following discussions in the upcoming LSF/MM:

* memcg kmem shrinking: as memory pressure appears within memcg, we need
to shrink some of the slab objects attributed to the group, maintaining
isolation as much as possible. The scheme also needs to allow for global
reclaim to keep working reliably, and of course, be memory efficient.

* memcg/global oom handling: I believe that the OOM killer could be
significantly improved to allow for more deterministic killing of tasks,
specially in containers scenarios where memcg is heavily deployed. In
some situations, a group encompasses a whole service, and under
pressure, it would be better to shut down the group altogether with all
its tasks, while in others it would be better to keep the current
behavior of shooting down a single task.

I also believe I will be able to help with general discussions
concerning the memory controller in general, since pursuing ways to
improve it - specially efficiency-wise - seems to be a recurring (and
thankfully fruitful) topic.

Re: [ATTEND][LSF/MM TOPIC] the memory controller

[Michel Lespinasse]

On Mon, Jan 28, 2013 at 12:11 AM, Lord Glauber Costa of Sealand
<glommer@parallels.com> wrote:
> * memcg/global oom handling: I believe that the OOM killer could be
> significantly improved to allow for more deterministic killing of tasks,
> specially in containers scenarios where memcg is heavily deployed. In
> some situations, a group encompasses a whole service, and under
> pressure, it would be better to shut down the group altogether with all
> its tasks, while in others it would be better to keep the current
> behavior of shooting down a single task.

We at Google have some OOM wish-list as well:
- having an option to kill the entire cgroup when a contained task is
selected to die;
- recursive setting of OOM kill priorities in a cgroup hierarchy

I am frankly not the best person to talk about this; however if this
topic was selected I could plan for it and bring on a few notes :)

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

--
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: [ATTEND][LSF/MM TOPIC] the memory controller

[Glauber Costa]

On 01/28/2013 12:11 PM, Lord Glauber Costa of Sealand wrote:
> Hi,
> 
> I've been working actively over the past year with the memory
> controller, in particular its usage to track special bits of interest in
> kernel memory land. As this work progress, I'd like to propose and
> participate in the following discussions in the upcoming LSF/MM:
> 
> * memcg kmem shrinking: as memory pressure appears within memcg, we need
> to shrink some of the slab objects attributed to the group, maintaining
> isolation as much as possible. The scheme also needs to allow for global
> reclaim to keep working reliably, and of course, be memory efficient.
> 

I have already posted some versions of it, that got quite some positive
feedback(*), at least from the MM side. Shrinking is something that can
be of interest for both mm and fs people, so maybe we could benefit for
having some joint discussion about it

* http://lwn.net/Articles/546472/