(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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
