lkml.org 
[lkml]   [2012]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications
On Thu, 15 Nov 2012, Anton Vorontsov wrote:

> Hehe, you're saying that we have to have cgroups=y. :) But some folks were
> deliberately asking us to make the cgroups optional.
>

Enabling just CONFIG_CGROUPS (which is enabled by default) and no other
current cgroups increases the size of the kernel text by less than 0.3%
with x86_64 defconfig:

text data bss dec hex filename
10330039 1038912 1118208 12487159 be89f7 vmlinux.disabled
10360993 1041624 1122304 12524921 bf1d79 vmlinux.enabled

I understand that users with minimally-enabled configs for an optimized
memory footprint will have a higher percentage because their kernel is
already smaller (~1.8% increase for allnoconfig), but I think the cost of
enabling the cgroups code to be able to mount a vmpressure cgroup (which
I'd rename to be "mempressure" to be consistent with "memcg" but it's only
an opinion) is relatively small and allows for a much more maintainable
and extendable feature to be included: it already provides the
cgroup.event_control interface that supports eventfd that makes
implementation much easier. It also makes writing a library on top of the
cgroup to be much easier because of the standardization.

I'm more concerned about what to do with the memcg memory thresholds and
whether they can be replaced with this new cgroup. If so, then we'll have
to figure out how to map those triggers to use the new cgroup's interface
in a way that doesn't break current users that open and pass the fd of
memory.usage_in_bytes to cgroup.event_control for memcg.

> OK, here is what I can try to do:
>
> - Implement memory pressure cgroup as you described, by doing so we'd make
> the thing play well with cpusets and memcg;
>
> - This will be eventfd()-based;
>

Should be based on cgroup.event_control, see how memcg interfaces its
memory thresholds with this in Documentation/cgroups/memory.txt.

> - Once done, we will have a solution for pretty much every major use-case
> (i.e. servers, desktops and Android, they all have cgroups enabled);
>

Excellent! I'd be interested in hearing anybody else's opinions,
especially those from the memcg world, so we make sure that everybody is
happy with the API that you've described.


\
 
 \ /
  Last update: 2012-11-15 22:41    [W:0.078 / U:0.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site