Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1431222ybv; Thu, 13 Feb 2020 23:16:03 -0800 (PST) X-Google-Smtp-Source: APXvYqygXteHrA9RvTlVb7c4a6bPCBs0Q1e6oA93E2cAlhlMiThl5c9garFMjZa8gjS8sK4SMnQ5 X-Received: by 2002:a9d:3e43:: with SMTP id h3mr1132652otg.84.1581664563712; Thu, 13 Feb 2020 23:16:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581664563; cv=none; d=google.com; s=arc-20160816; b=O05k3ibOiZWHz6MMfzBjmyH979VgO5kMhGghFj2bdcvOgtYjY8I8LJZQHu3rJ/KEr3 IpZvd4PjtZQHAtXMq2hYoNcxM37j1CuJoDeIhdSZPBQd0sfUH0SlqpDfpfu4dYmqDyuA A0veXmH2B6fTxVb2usBnO+yAOSTDd0h97nXB2H1IFjIZ9T8UAdavjaEeq6Gg0yahmTUQ XhlKpoEH/mi+CqGE3GJhegfwie5BH/r/KbiP4d7SJ0keVKFciSjYXDrIqHmQBG+ZXG0P RHMtmH7ry/gOggIJqGhkDtlD2jQ7MBCahIZNh+j/ePU/yMgeAuvImDqQQXCfOVsDhKth 9qsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=F0xj7bH5swJh/Jvt4q2hyWK65GDCtgJ1J8rbJbB5Suo=; b=bxsptwxCebiVet+QwfDTtHfsKdHmY98GFLUnfmYwzh/WyGrH/ag8IeQULp53Uh9I7S urBEX+46HNjshPf/NXIe/Ywh0YuSDhlGhvM0o49FBS1mdy2xmPrJPpiVdMoh8bYKLaTA QiwsrU4OPbo4ntrIVMQDHEd6z5+goISsFfpxk2jHmQp1DDWhD86utVbLJr7LguAtlKQZ ABxO215ZCRL1j3q7IMJCkHONJyJs4bk4J604ivrizfM5Qgg+JP5zhO97q24a0/d8Qt1R 6olYoDIfvfCOgw/ams0Y+qJErQrhb3j0B3yzRBq9oo7bJ/Uc7KFL1AIgH1RW3Tg6KjL4 bExg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a92si2383428otc.294.2020.02.13.23.15.51; Thu, 13 Feb 2020 23:16:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728879AbgBNHPm (ORCPT + 99 others); Fri, 14 Feb 2020 02:15:42 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:40523 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728740AbgBNHPm (ORCPT ); Fri, 14 Feb 2020 02:15:42 -0500 Received: by mail-wr1-f67.google.com with SMTP id t3so9657362wru.7; Thu, 13 Feb 2020 23:15:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=F0xj7bH5swJh/Jvt4q2hyWK65GDCtgJ1J8rbJbB5Suo=; b=R4CzYAaNp66z6Z9oNzFeVsyFrT6cbz7WR/dibEF3m4KjJctHk6S99F1G1v1OHO87NR 1tvZKbywlsG5AV0v2r54gaDj27DArQHIBHQ8Sb0WzsBgeLzW1GMkmUqpAsQca12WvasY x1Ck+/1xMyR8m0ieRbkk41ZThLvyygA06Dr3OE719Ao6FQl8sRydH2C0hKt/HzOU77yQ gCIxk3Z8QAy1XjONKFQ5+JXMTzHYRUf+ZbBFSg9HMeWxBflFcXzczpd/Mu2s6TTHpaF4 bXJ1wAzNpC2URBOTa7IdkoqTwRqoCN5KzdIiXVhCI+UqRavbxtBwufti5mUPsNbN1aIV E5Kw== X-Gm-Message-State: APjAAAXcnJP/J7DYo0U9UocOjLxusUJEKGXnWMgN1IcMX1hXvlGtquUP UBFPfhUdRmA9wB2u+gK9Sg0= X-Received: by 2002:adf:8296:: with SMTP id 22mr2310663wrc.352.1581664539776; Thu, 13 Feb 2020 23:15:39 -0800 (PST) Received: from localhost (ip-37-188-133-87.eurotel.cz. [37.188.133.87]) by smtp.gmail.com with ESMTPSA id q1sm5768332wrw.5.2020.02.13.23.15.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Feb 2020 23:15:38 -0800 (PST) Date: Fri, 14 Feb 2020 08:15:37 +0100 From: Michal Hocko To: Tejun Heo Cc: Johannes Weiner , Andrew Morton , Roman Gushchin , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 3/3] mm: memcontrol: recursive memory.low protection Message-ID: <20200214071537.GL31689@dhcp22.suse.cz> References: <20200130170020.GZ24244@dhcp22.suse.cz> <20200203215201.GD6380@cmpxchg.org> <20200211164753.GQ10636@dhcp22.suse.cz> <20200212170826.GC180867@cmpxchg.org> <20200213074049.GA31689@dhcp22.suse.cz> <20200213135348.GF88887@mtj.thefacebook.com> <20200213154731.GE31689@dhcp22.suse.cz> <20200213155249.GI88887@mtj.thefacebook.com> <20200213163636.GH31689@dhcp22.suse.cz> <20200213165711.GJ88887@mtj.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200213165711.GJ88887@mtj.thefacebook.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 13-02-20 11:57:11, Tejun Heo wrote: > Hello, > > On Thu, Feb 13, 2020 at 05:36:36PM +0100, Michal Hocko wrote: > > AFAIK systemd already offers knobs to configure resource controls [1]. > > Yes, it can set up the control knobs as directed but it doesn't ship > with any material resource configurations or has conventions set up > around it. Right. But services might use those knobs, right? And that means that if somebody wants a memory protection then the service file is going to use MemoryLow=$FOO and that is likely not going to work properly without an an additional hassles, e.g. propagate upwards, which systemd doesn't do unless I am mistaken. > > Besides that we are talking about memcg features which are available only > > unified hieararchy and that is what systemd is using already. > > I'm not quite sure what the above sentence is trying to say. I meant to say that once the unified hierarchy is used by systemd you cannot configure it differently to suit your needs without interfering with systemd. > > > You gotta > > > change the layout to configure resource control no matter what and > > > it's pretty easy to do. systemd folks are planning to integrate higher > > > level resource control features, so my expectation is that the default > > > layout is gonna change as it develops. > > > > Do you have any pointers to those discussions? I am not really following > > systemd development. > > There's a plan to integrate streamlined implementation of oomd into > systemd. There was a thread somewhere but the only thing I can find > now is a phoronix link. > > https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Facebook-OOMD I am not sure I see how that is going to change much wrt. resource distribution TBH. Is the existing cgroup hierarchy going to change for the OOMD to be deployed? [...] > > Anyway, I am skeptical that systemd can do anything much more clever > > than placing cgroups with a resource control under the root cgroup. At > > least not without some tagging which workloads are somehow related. > > Yeah, exactly, all it needs to do is placing scopes / services > according to resource hierarchy and configure overall policy at higher > level slices, which is exactly what the memory.low semantics change > will allow. Let me ask more specifically. Is there any plan or existing API to allow to configure which services are related resource wise? > > That being said, I do not really blame systemd here. We are not making > > their life particularly easy TBH. > > Do you mind elaborating a bit? I believe I have already expressed the configurability concern elsewhere in the email thread. It boils down to necessity to propagate protection all the way up the hierarchy properly if you really need to protect leaf cgroups that are organized without a resource control in mind. Which is what systemd does. -- Michal Hocko SUSE Labs