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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 D3541C2BA83 for ; Thu, 13 Feb 2020 07:40:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9FFD821734 for ; Thu, 13 Feb 2020 07:40:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9FFD821734 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 1E7D16B051A; Thu, 13 Feb 2020 02:40:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 198A86B051B; Thu, 13 Feb 2020 02:40:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0888D6B051C; Thu, 13 Feb 2020 02:40:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id E24086B051A for ; Thu, 13 Feb 2020 02:40:54 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 90236180AD815 for ; Thu, 13 Feb 2020 07:40:54 +0000 (UTC) X-FDA: 76484307228.08.fold22_5f30e0a2d8149 X-HE-Tag: fold22_5f30e0a2d8149 X-Filterd-Recvd-Size: 6743 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Feb 2020 07:40:54 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id t3so5366439wru.7 for ; Wed, 12 Feb 2020 23:40:53 -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=VikzcxuvzZjt5786Kga/OPgmPI0d+YsoVj/K9eGOyeU=; b=HXE/iW0dEyVw7efbivZDpX3I2GKTvpcRIY8o5S7SV3I3HpHpeTF5kJmUrEB8N3csLW uxehPSsIySJaiGKrqaliit5+yv6ifmoW+gQDjTF4iefXYwc99Kls/DgKQf2j6wQRk3UX 4TYv3S/bJ3WmjTRtnarXKYvQE0k2GCJOXOHnaRn7t16PEoDUnyP3tinbDB8zZovcXVuP dxvFRzkwE6Z1QXZsziHlJXXVOyPzvngzjkpO20ApP9h0b3MY/OGOOecL9of1N/v252TF tum15Lg69ZJ0AWzhWOwSb7kPrLGX4BYk0xjGwK2UcGJJ5NULPRLrk5M1StOUxVAClydR B3zw== X-Gm-Message-State: APjAAAWMntbmFwsTOInvUGl+GP4Vb8SoReNRvGI/p2+LLXoW4az8fGbl iD+W/ZvSXnk31tkgl47DBi0= X-Google-Smtp-Source: APXvYqxKmZsq/EnT/yDwMIc+CtkJTjfoRHXWLR4Gm98glFGipcPyrbjpdbh0emtezP9vHCwVFkIj9w== X-Received: by 2002:adf:f084:: with SMTP id n4mr19962569wro.200.1581579652792; Wed, 12 Feb 2020 23:40:52 -0800 (PST) Received: from localhost (ip-37-188-133-87.eurotel.cz. [37.188.133.87]) by smtp.gmail.com with ESMTPSA id q1sm1708500wrw.5.2020.02.12.23.40.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2020 23:40:51 -0800 (PST) Date: Thu, 13 Feb 2020 08:40:49 +0100 From: Michal Hocko To: Johannes Weiner Cc: Andrew Morton , Roman Gushchin , Tejun Heo , 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: <20200213074049.GA31689@dhcp22.suse.cz> References: <20191219200718.15696-1-hannes@cmpxchg.org> <20191219200718.15696-4-hannes@cmpxchg.org> <20200130170020.GZ24244@dhcp22.suse.cz> <20200203215201.GD6380@cmpxchg.org> <20200211164753.GQ10636@dhcp22.suse.cz> <20200212170826.GC180867@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200212170826.GC180867@cmpxchg.org> 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: On Wed 12-02-20 12:08:26, Johannes Weiner wrote: > On Tue, Feb 11, 2020 at 05:47:53PM +0100, Michal Hocko wrote: > > Unless I am missing something then I am afraid it doesn't. Say you have a > > default systemd cgroup deployment (aka deeper cgroup hierarchy with > > slices and scopes) and now you want to grant a reclaim protection on a > > leaf cgroup (or even a whole slice that is not really important). All the > > hierarchy up the tree has the protection set to 0 by default, right? You > > simply cannot get that protection. You would need to configure the > > protection up the hierarchy and that is really cumbersome. > > Okay, I think I know what you mean. Let's say you have a tree like > this: > > A > / \ > B1 B2 > / \ \ > C1 C2 C3 > > and there is no actual delegation point - everything belongs to the > same user / trust domain. C1 sets memory.low to 10G, but its parents > set nothing. You're saying we should honor the 10G protection during > global and limit reclaims anywhere in the tree? No, only in the C1 which sets the limit, because that is the woriking set we want to protect. > Now let's consider there is a delegation point at B1: we set up and > trust B1, but not its children. What effect would the C1 protection > have then? Would we ignore it during global and A reclaim, but honor > it when there is B1 limit reclaim? In the scheme with the inherited protection it would act as the gate and require an explicit low limit setup defaulting to 0 if none is specified. > Doing an explicit downward propagation from the root to C1 *could* be > tedious, but I can't think of a scenario where it's completely > impossible. Especially because we allow proportional distribution when > the limit is overcommitted and you don't have to be 100% accurate. So let's see how that works in practice, say a multi workload setup with a complex/deep cgroup hierachies (e.g. your above example). No delegation point this time. C1 asks for low=1G while using 500M, C3 low=100M using 80M. B1 and B2 are completely independent workloads and the same applies to C2 which doesn't ask for any protection at all? C2 uses 100M. Now the admin has to propagate protection upwards so B1 low=1G, B2 low=100M and A low=1G, right? Let's say we have a global reclaim due to external pressure that originates from outside of A hierarchy (it is not overcommited on the protection). Unless I miss something C2 would get a protection even though nobody asked for it. > And the clarity that comes with being explicit is an asset too, > IMO. Since it has an effect at the reclaim level, it's not a bad thing > to have that effect *visible* in the settings at that level as well: > the protected memory doesn't come out of thin air, it's delegated down > from the top where memory pressure originates. So how are we going to deal with hierarchies where the actual workload of interest is a leaf deeper in the hierarchy and the upper levels of the hierarchy are shared between unrelated workloads? Look at how systemd organizes system into cgroups for example (slices vs. scopes) and say you want to add a protection to a single user or a service. > My patch is different. It allows a configuration that simply isn't > possible today: protecting C1 and C2 from C3, without having to > protect C1 and C2 from each other. > > So I don't think requiring an uninterrupted, authorized chain of > protection from the top is necessarily wrong. In fact, I think it has > benefits. But requiring the protection chain to go all the way to the > leaves for it to have any effect, that is a real problem, and it can't > be worked around. Yes I do agree that the problem you are dealing with is slightly different. My main point was that you are already introducing a new semantic which is not fully backward compatible and I figured we have more problems in the area and maybe we can introduce a semantic to handle both above mentioned scenarios while doing that. -- Michal Hocko SUSE Labs