lkml.org 
[lkml]   [2015]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy
    On Fri, Nov 06, 2015 at 11:19:53AM -0500, Johannes Weiner wrote:
    > On Fri, Nov 06, 2015 at 11:57:24AM +0100, Michal Hocko wrote:
    > > On Thu 05-11-15 17:52:00, Johannes Weiner wrote:
    > > > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote:
    > > > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote:
    > > > > > This would be true if they moved on to the new cgroup API intentionally.
    > > > > > The reality is more complicated though. AFAIK sysmted is waiting for
    > > > > > cgroup2 already and privileged services enable all available resource
    > > > > > controllers by default as I've learned just recently.
    > > > >
    > > > > Have you filed a report with them? I don't think they should turn them
    > > > > on unless users explicitely configure resource control for the unit.
    > > >
    > > > Okay, verified with systemd people that they're not planning on
    > > > enabling resource control per default.
    > > >
    > > > Inflammatory half-truths, man. This is not constructive.
    > >
    > > What about Delegate=yes feature then? We have just been burnt by this
    > > quite heavily. AFAIU nspawn@.service and nspawn@.service have this
    > > enabled by default
    > > http://lists.freedesktop.org/archives/systemd-commits/2014-November/007400.html
    >
    > That's when you launch a *container* and want it to be able to use
    > nested resource control.
    >
    > We're talking about actual container users here. It's not turning on
    > resource control for all "privileged services", which is what we were
    > worried about here. Can you at least admit that when you yourself link
    > to the refuting evidence?
    >
    > And if you've been "burnt quite heavily" by this, where is your bug
    > report to stop other users from getting "burnt quite heavily" as well?
    >

    I didn't read this thread in detail but the lack of public information on
    problems with cgroup controllers is partially my fault so I'd like to correct
    that.

    https://bugzilla.suse.com/show_bug.cgi?id=954765

    This bug documents some of the impact that was incurred due to ssh
    sessions being resource controlled by default. It talks primarily about
    pipetest being impacted by cpu,cpuacct. It is also found in the recent
    past that dbench4 was previously impacted because the blkio controller
    was enabled. That bug is not public but basically dbench4 regressed 80% as
    the journal thread was in a different cgroup than dbench4. dbench4 would
    stall for 8ms in case more IO was issued before the journal thread could
    issue any IO. The opensuse bug 954765 bug is not affected by blkio because
    it's disabled by a distribution-specific patch. Mike Galbraith adds some
    additional information on why activating the cpu controller can have an
    impact on semantics even if the overhead was zero.

    It may be the case that it's an oversight by the systemd developers and the
    intent was only to affect containers. My experience was that everything
    was affected. It also may be the case that this is an opensuse-specific
    problem due to how the maintainers packaged systemd. I don't actually
    know and hopefully the bug will be able to determine if upstream is really
    affected or not.

    There is also a link to this bug on the upstream project so there is some
    chance they are aware https://github.com/systemd/systemd/issues/1715

    Bottom line, there is legimate confusion over whether cgroup controllers
    are going to be enabled by default or not in the future. If they are
    enabled by default, there is a non-zero cost to that and a change in
    semantics that people may or may not be surprised by.

    --
    Mel Gorman
    SUSE Labs


    \
     
     \ /
      Last update: 2015-11-12 20:01    [W:3.397 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site