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

[Tejun Heo]

(cc'ing Johannes and quoting the whole body for context)

Hey, guys.

On Thu, Oct 10, 2013 at 10:28:16AM -0400, Tejun Heo wrote:
> 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.

I talked with Johannes about the knobs and think something like the
following could be useful.

* A swap knob, which, when set, configures memsw.limit_in_bytes to
  memory.limit_in_bytes + the set value.

* A switch to enable kmem.  When enabled, kmem.limit_in_bytes tracks
  memory.limit_in_bytes.  ie. kmem is accounted and both kernel and
  user memory live under the same memory limit.

* A kmem knob which can be optionally configured to a lower value than
  memory.limit_in_bytes.  This is useful for overcommit scenarios as
  explained in Documentation/cgroups/memory.txt::2.7.3.

* tcp knobs are currently completely separate from other memory
  limits.  This should probably be included in memory.limit_in_bytes.
  I think it probably is a better idea to hold off on this one.

* What softlimit means is still very unclear.  We might end up with
  explicit guarantee knob and keep softlimit as it is, whatever it
  currently means.

Caveats

* This setup doesn't allow setting (memory + swap) limit without
  setting memory limit.

* The overcommit scenario described in memory.txt::2.7.3 is somewhat
  bogus because not all userland memory is reclaimable and not all
  kernel memory is unreclaimable.  Oh well...

Thanks.

-- 
tejun