From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10E93C3B18D for ; Thu, 13 Feb 2020 16:57:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C9055222C2 for ; Thu, 13 Feb 2020 16:57:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pka2Qi2f" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9055222C2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 663606B057D; Thu, 13 Feb 2020 11:57:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5EDE96B057F; Thu, 13 Feb 2020 11:57:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F34A6B0580; Thu, 13 Feb 2020 11:57:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) by kanga.kvack.org (Postfix) with ESMTP id 1D2126B057D for ; Thu, 13 Feb 2020 11:57:14 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A7E8B181AEF10 for ; Thu, 13 Feb 2020 16:57:13 +0000 (UTC) X-FDA: 76485709146.02.soda66_4d260d2db511 X-HE-Tag: soda66_4d260d2db511 X-Filterd-Recvd-Size: 5743 Received: from mail-qv1-f68.google.com (mail-qv1-f68.google.com [209.85.219.68]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Feb 2020 16:57:12 +0000 (UTC) Received: by mail-qv1-f68.google.com with SMTP id m5so2927999qvv.4 for ; Thu, 13 Feb 2020 08:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/9pAJl5lwO/l/LEFjlIiSIPtfDfflLg/CjlywKeZ4W0=; b=pka2Qi2fbd4HXtA3HE9p7vhJ6JpjDs0dwsLG0U+e+THmClapZAuyNGAXaL5mEj5uQq 3s/RQwhkHiv6KWwihYhaeNTXKGqk4U374R5+UjJXesDuYKEzBXCMXJCgEpQBMCxPnDCS 5jowrfBMqUdowxvefJdPm6iqwb/LNFkrv5MZ/fBv4iTL2wrVypqI6oHgm2pS2mqSsPNE 6UIq7Wkt1Rk9cPW8ee159csvhfNdZMOPWpZM95gXav8SFLtL7tgVPVfpE/Dp1ZoZynqn Hj8iF2bqUlyu9r5/ROJxIRGMnT4izUTycemTJT1HXfkqreQteC/5+FWT+wAUz7O43kK6 ZQ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=/9pAJl5lwO/l/LEFjlIiSIPtfDfflLg/CjlywKeZ4W0=; b=jZoVo96Jccc523e4A+/0oTIYocTzyUzMewuPiqEhPyAEkKv00cxJzL4m0VAZgvLNk1 L3h726wdjlqWOva39tJ2TsaCXd/XAVJNNIuM7aCSmtbs4l/bQnH/rUakFko2W0yC7Ye0 taZ7+xAkBf5ELX6TVvNR6k+gwZQ6w/egYHUIr4hc4iL3qKyvhP0196t2cqsjD/k+6k5m oM2tfP0NgIXXmtlDkFcHyADhyqy691X1KGsiQaC+dXNI+FfWkSbTsDwjgfzDZ8ucmJHf xHvs8tksGvQ1rGlgt8vBHrvrnFgIRlH+LPRqR+trpwjMRAz1G/OnszGNK1mIt72361TD RPXA== X-Gm-Message-State: APjAAAXkVVAzfj1iBhQLODwvEF6WlGabwzlklyf2ahd9lIZgRKedHqxO R8NluIhX8lXR3i8bw56Ndc4= X-Google-Smtp-Source: APXvYqyyUaff9xV5SspGMT2JokOmkLiKM0IXP359cQEe38/yhvST+XYtFtBy5Z72J3GInW5pUHEk0g== X-Received: by 2002:ad4:5525:: with SMTP id ba5mr11972282qvb.117.1581613032367; Thu, 13 Feb 2020 08:57:12 -0800 (PST) Received: from localhost ([2620:10d:c091:500::2:94a4]) by smtp.gmail.com with ESMTPSA id f2sm177161qkm.81.2020.02.13.08.57.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Feb 2020 08:57:11 -0800 (PST) Date: Thu, 13 Feb 2020 11:57:11 -0500 From: Tejun Heo To: Michal Hocko 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: <20200213165711.GJ88887@mtj.thefacebook.com> References: <20191219200718.15696-4-hannes@cmpxchg.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200213163636.GH31689@dhcp22.suse.cz> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. > 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. > > 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 systemd recently implemented DisableControllers so that upper level slices can have authority over what controllers are enabled below it and in a similar vein there were discussions over making it auto-propagate some of the configs down the hierarchy but kernel doing the right thing and maintaining consistent semantics across controllers seems to be the right approach. There was also a discussion with a distro. Nothing concrete yet but I think we're more likely to see more resource control configs being deployed by default in the future. > 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. > 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? Thanks. -- tejun