Re: Android low memory killer vs. memory pressure notifications

[David Rientjes]

On Wed, 21 Dec 2011, Anton Vorontsov wrote:

> > It's helpful for certain end users, particularly those in the embedded 
> > world, to be able to disable as many config options as possible to reduce 
> > the size of kernel image as much as possible, so they'll want a minimal 
> > amount of kernel functionality that allows such notifications.  Keep in 
> > mind that CONFIG_CGROUP_MEM_RES_CTLR is not enabled by default because of 
> > this (enabling it, CONFIG_RESOURCE_COUNTERS, and CONFIG_CGROUPS increases 
> > the size of the kernel text by ~1%),
> 
> So for 2MB kernel that's about 20KB of an additional text... This seems
> affordable, especially as a trade-off for the things that cgroups may
> provide.
> 

No, this was with defconfig and then defconfig + CONFIG_CGROUPS + 
CONFIG_RESOURCE_COUNTERS + CONFIG_CGROUP_MEM_RES_CTLR.  Configs that want 
a very small kernel image will definitely not be running with defconfig, 
they'll be using a stripped down version that allows for the smallest 
footprint possible.  Requiring those config options would then increase 
the size of the kernel text by much more than 1%.

Compare this situation with using CONFIG_SLOB for embedded devices (which 
is actually quite popular) over CONFIG_SLAB and CONFIG_SLUB specifically 
for that low memory footprint.

> The fact is, for desktop and server Linux, cgroups slowly becomes a
> mandatory thing.

And that's definitely in the wrong direction for Linux.  It would be like 
asking users to convert to slab or slub because we don't want to maintain 
a slob allocator that is specifically designed for an extremely low memory 
footprint.  Such a proposal would be rejected outright unless you could 
match the same footprint with the alternatives.

> As Alan Cox pointed out, we should probably focus on improving (if needed)
> existing solutions, instead of duplicating functionality for the sake of
> doing the same thing, but in a more "lightweight" and ad-hocish way.
> 

I'm very in favor of extracting out notifiers of low-memory situations and 
extended for global use rather than tying it specifically to the memory 
controller.  Then, memcg would be responsible only for limitation of 
resources rather than tying additional functionality to it that would be 
generally useful to everyone (memory notifiers) and requiring them to 
incur the overhead of memcg.

> > and it's becoming increasingly 
> > important for certain workloads to be notified of low memory conditions 
> > without any restriction on its usage other than the amount of RAM that the 
> > system has
> 
> I'm not sure what you mean here. Mem_cg may provide a way to the
> userland to be notified on low memory conditions, i.e. amount of RAM
> that the system has -- the same thing as /dev/mem_notify would do...
> 

Yes, but without the requirements of the above-mentioned subsystems.  The 
point here is that some embedded devices may want notification of low-
memory conditions without the overhead (both size and performance) of 
cgroups or memcg.  Please focus on that specifically.
--
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/