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

[Mika Eloranta]

Hi,

Thanks guys for the feedback. I'm interested in using these controls
in dense environments (read: overcommitted memory), where striking
a good balance requires individual tuning of these settings.

I'm actually also eyeballing swappiness, pressure_level notifications 
and oom_control (each currently not supported directly by systemd's 
cgroup settings). Do you think adding those would be feasible? I'm
a bit new to systemd's code, but willing to spend some time getting
it done properly...

Another option could be just to provide a proxy interface for setting
any user-defined cgroup attributes, which would shift the responsibility
of using it correctly to the user. Something like:

  CGroupAttributes=memory.kmem.limit_in_bytes=10240000,memory.kmem.tcp.limit_in_bytes=102400

Some of these (excl. kmem) could be tuned outside systemd, but they'd
be much nicer to use directly from systemd's standard configuration.

Cheers,

	- Mika

On Oct 10, 2013, at 17:28, 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.
> 
> Thanks!
> 
> -- 
> tejun