the memory controller
Subsystems (2)
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.
Quoted 7 lines · Lord Glauber Costa of Sealand
* 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 :)
Signature · 8 lines
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 [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 7 lines · 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:
Quoted 5 lines
* 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