Re: [PATCH v2] memcg: Add memory.pressure_level events
From: Anton Vorontsov
Date: Fri Feb 22 2013 - 01:59:50 EST
On Fri, Feb 22, 2013 at 08:56:08AM +0900, Minchan Kim wrote:
> [...] The my point is that you have a plan to support? Why I have a
> question is that you said your goal is to replace lowmemory killer
In short: yes, of course, if the non-memcg interface will be in demand.
> but android don't have enabled CONFIG_MEMCG as you know well
> so they should enable it for using just notifier? or they need another hack to
> connect notifier to global thing?
A hack is not an option for me. :-) My final goal is to switch Android to
use the notifier without need for hacks/external patches or
But my current goal is to make the most generic case work, and do this in
the most correct way. That is, vmpressure + MEMCG. Once I accomplish this,
I can then think of any niche needs (such as Android).
There will be two possibilities for Android:
1. Obviously, turn on CONFIG_MEMCG. We need to measure its effect on real
devices, and see if it makes sense. (Plus, maybe there are other uses
for MEMCG on Android?)
2. Implement /sys/fs/cgroups/memory/memory.pressure_level interface
without MEMCG. Doing this will be really easy as we'll already have
vmpressure() core, and Android has CROUPS=y. But I do expect some
discussion like 'why don't you fix memcg instead?'. We'll have to
answer this question by looking back at '1.'
Also note that cgroups vmpressure notifiers were tried by QEMU folks, and
it seemed to be useful:
So, nowadays it is not only about Android. Some time ago I also got an
email from Orna Agmon Ben-Yehuda, who suggested to use vmpressure stuff
with 'memcached' (but I didn't find time to actually try it, so far. :(
Thanks for the email, btw!).
So it is useful with or without MEMCG, and if we will really need to
support vmpressure without MEMCG, I will have to implement the support in
addition to MEMCG case, yes.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/