[systemd-devel] [PATCH 1/4] cgroups: support for MemoryAndSwapLimit= setting

[Tejun Heo]

Hello,

On Thu, Oct 10, 2013 at 04:03:20PM +0200, Lennart Poettering wrote:
> For example MemorySoftLimit is something we supported previously, but
> which I recently removed because Tejun Heo (the kernel cgroup
> maintainer, added to CC) suggested that the attribute wouldn't continue
> to exist on the kernel side or at least not in this form.

The problem with the current softlimit is that we currently aren't
sure what it means.  Its semantics is defined only by its
implementation details with all its quirks and different parties
interpret and use it differently.  memcg people are trying to clear
that up so I think it'd be worthwhile to wait to see what happens
there.

> Tejun, Mika sent patches to wrap memory.memsw.limit_in_bytes,
> memory.kmem.limit_in_bytes, memory.soft_limit_in_bytes,
> memory.kmem.tcp.limit_in_bytes in high-level systemd attributes. Could
> you comment on the future of these attributes in the kernel? Should we
> expose them in systemd?
> 
> At the systemd hack fest in New Orleans we already discussed
> memory.soft_limit_in_bytes and memory.memsw.limit_in_bytes and you
> suggested not to expose them. What about the other two?

Except for soft_limit_in_bytes, at least the meanings of the knobs are
well-defined and stable, so I think it should be at least safe to
expose those.

> (I have the suspicion though that if we want to expose something we
> probably want to expose a single knob that puts a limit on all kinds of
> memory, regardless of "RAM", "swap", "kernel" or "tcp"...)

Yeah, the different knobs grew organically to cover more stuff which
wasn't covered before, so, yeah, when viewed together, they don't
really make a cohesive sense.  Another problem is that, enabling kmem
knobs would involve noticeable amount of extra overhead.  kmem also
has restrictions on when it can be enabled - it can't be enabled on a
populated cgroup.

Maybe an approach which makes sense is where one sets the amount of
memory which can be used and toggle which types of memory should be
included in the accounting.  Setting kmem limit equal to that of
limit_in_bytes makes limit_in_bytes applied to both kernel and user
memories.  I'll ask memcg people and find out how viable such approach
is.

Thanks!

-- 
tejun