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_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,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 BA1A9C3B186 for ; Wed, 12 Feb 2020 17:08:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7AFEB20658 for ; Wed, 12 Feb 2020 17:08:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="O6bqdQqB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7AFEB20658 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 22B736B046E; Wed, 12 Feb 2020 12:08:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DD266B046F; Wed, 12 Feb 2020 12:08:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0CB296B0470; Wed, 12 Feb 2020 12:08:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id E4DE46B046E for ; Wed, 12 Feb 2020 12:08:29 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8BFF9181AEF10 for ; Wed, 12 Feb 2020 17:08:29 +0000 (UTC) X-FDA: 76482108738.15.drain41_2ce8882762422 X-HE-Tag: drain41_2ce8882762422 X-Filterd-Recvd-Size: 5584 Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Wed, 12 Feb 2020 17:08:28 +0000 (UTC) Received: by mail-qk1-f196.google.com with SMTP id a2so2720184qko.12 for ; Wed, 12 Feb 2020 09:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=HsBl5rMluvvE/pco2RfgwIL5+jpMuMRec38m/p38OMc=; b=O6bqdQqB754/215opJE3M7EUYVTUIhhbCE2lNZaklstLauxL4cB6U5Lkm8nLa6ai+V M6T/WjrYmfRSVrpnvIulIoWhLs9eS8Y55Aariv3m4POcoSqfrPc52/AL5HHw49GU3aro q9emBN3umt3HPcAAZjNvc7ea18lJ/hn8Q3S4jrizD022B9CE+zN+WAsr6FS6zAPsSER0 lkBBVZbw1FZR9AD9LiyKVVyyqDxsGlA8Ky4TnhMZQhNdW8OGVXr8cXXeIQ1SLHE1IhDD yb2N6V11ijw8SEjuvEiC7qqWBmpm6xRnSyJIfQPhV6KRUx6DOyATDYdS8rZ1mEZvPFQy lORA== 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=HsBl5rMluvvE/pco2RfgwIL5+jpMuMRec38m/p38OMc=; b=gWQPc9BN5lBQaTuBvvM9+KTqVEzZgNwChg0KQanVzg/nTrqV7A/SSCcbjVQKO3h+gF CG33ogvJRJGojat+4xo7j8rLfX6kN0kANgKm/7TFOKMrTcSULAoXtMoF6hQvAK5i5zq+ +swmymAOMHplFdKSyhjNs6sgiUL56gwvsjg+XL4whfXMimlHXayaRp6XlifMzj6nJMU0 J/Apg5waPCfAfxdn1rbC++WEhlhy20+ZRF0xHuf83KNzoTqi58gDkO4VQA58E8maivD2 ohBVT+CjUO0JmoPJ81Ndld92OH6WWaVuki2JvOCSYA/jhxwY4tSwgAuiBODjVxtyYWY1 zIbQ== X-Gm-Message-State: APjAAAXQU8P6mQh2o8uv5SzXsgwH7IaF8EKYBkSGmSgQc/cHu3B4sHkd 6t3vM7JS78/zCAejpM1boRKJ6g== X-Google-Smtp-Source: APXvYqzFArg0u7ixTyn9XIaPgPpptQEFElmY295g4IC8sWja/fFRjB35UdOOImoT6soG8zmA6a9W0w== X-Received: by 2002:a37:e409:: with SMTP id y9mr12047308qkf.352.1581527307550; Wed, 12 Feb 2020 09:08:27 -0800 (PST) Received: from localhost ([2620:10d:c091:500::2:26be]) by smtp.gmail.com with ESMTPSA id o6sm495462qkk.53.2020.02.12.09.08.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2020 09:08:26 -0800 (PST) Date: Wed, 12 Feb 2020 12:08:26 -0500 From: Johannes Weiner To: Michal Hocko 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: <20200212170826.GC180867@cmpxchg.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200211164753.GQ10636@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: 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? 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? 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. 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. 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.