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 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 301CBC3B18B for ; Thu, 13 Feb 2020 13:53:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E8EA924649 for ; Thu, 13 Feb 2020 13:53:51 +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="RD/t0DYR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8EA924649 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 849726B0545; Thu, 13 Feb 2020 08:53:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D3D96B0547; Thu, 13 Feb 2020 08:53:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69C346B0548; Thu, 13 Feb 2020 08:53:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) by kanga.kvack.org (Postfix) with ESMTP id 4CB5B6B0545 for ; Thu, 13 Feb 2020 08:53:51 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E38101260 for ; Thu, 13 Feb 2020 13:53:50 +0000 (UTC) X-FDA: 76485247020.11.month39_47132a0dcc04 X-HE-Tag: month39_47132a0dcc04 X-Filterd-Recvd-Size: 4909 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Feb 2020 13:53:50 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id d11so5677163qko.8 for ; Thu, 13 Feb 2020 05:53:50 -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=NlK/bjEFsXh3ZUaRYaJXsg13O7KnRNlLmTitoPpLaEE=; b=RD/t0DYRkjg2v0l7LbvA1SM3AhbagXxt34WCWdJhaFpgAzoMY6e+khjk2cwPGiR10D aTFgnm5hT+CUSE4PuyoIcbZGiMBw7krH7p2VHybmp6fcs7owpHIAifcL7TuNJ1HKRXNH 0wZN68Y99o9IJh+nKtSLFVurRhV/pla+3AZxXyAwMq6ifvSw/w33GOVWIBjgAGEbr+cx ttic9M1HePVTJBn7XEeY5P/9nk5eQpVDFRNKpwB0ueYpnmBijtIECdbY+eawzmMM0vme CwWnXscLtVr9I9yGj29HLPTB2lhjTczuCOTtgZ9WbuCCtFU3F43OwD6ecTUG9Gnqom/i ieVg== 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=NlK/bjEFsXh3ZUaRYaJXsg13O7KnRNlLmTitoPpLaEE=; b=M55jH2ReOe0aGX/3XR1/O9OpGV3U59R+BJ+scbsU3cWZoMB1JRWR21QKxI5pmVPX8N DAVOlU35aDwrpT+aZdyejfqlogC1CYN6mskmZ6JjzaZMi47ux7Gg76MZDBngNq/DF2o+ I0rZXRBSeEi+yDj9cTfUjU5qZscl6MoEwWY+sQdXjjthmOQXxJDIcaDz8xH+CjK84ajf 938FqEPD0QFcrvzbP8zssB+Ylu4ssARDSwwyvHAlgy98NwwJugCvr0vMForEAAth3RMC l2hl3N+0Aaml6ye+oenK3nfmwgPkPWlAyW8wljLQZeL/MJvJiP+rXpcCejVBWCzJFBS+ sh7g== X-Gm-Message-State: APjAAAUOmMAyxXasBnOpc1sMFkENp2w/mz/WGXH8H1FKz54k0912elya LQzDAdiSZqS/Njknvm1DMJk= X-Google-Smtp-Source: APXvYqz5u80waaYGchbdKXvEMTIeavCdnxOzKq9fHUfxpwnBb49hqgHwLX5XvMlBjyEKhebBD7m2yw== X-Received: by 2002:a37:dd8:: with SMTP id 207mr15467412qkn.292.1581602029790; Thu, 13 Feb 2020 05:53:49 -0800 (PST) Received: from localhost ([2620:10d:c091:500::1:f3be]) by smtp.gmail.com with ESMTPSA id p26sm1309845qkp.34.2020.02.13.05.53.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Feb 2020 05:53:49 -0800 (PST) Date: Thu, 13 Feb 2020 08:53:48 -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: <20200213135348.GF88887@mtj.thefacebook.com> 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> <20200213074049.GA31689@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200213074049.GA31689@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, Michal. On Thu, Feb 13, 2020 at 08:40:49AM +0100, Michal Hocko wrote: > 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. The above scenario where descendants of a cgroup behave unrelated to each other sound plausible in theory but doesn't really work in practice because memory management is closely tied with IO and all IO control mechanisms are strictly hierarchical and arbitrate level-by-level. A workload's memory footprint can't be protected without protecting its IOs and a descendant cgroup's IOs can't be protected without protecting its ancestors, so implementing that in memory controller in isolation, while doable, won't serve many practical purposes. It just ends up creating cgroups which are punished on memory while greedly burning up IOs. The same pattern for CPU control, so for any practical configuration, the hierarchy layout has to follow the resource distribution hierarchy of the system - it's what the whole thing is for after all. The existing memory.min/low semantics is mostly from failing to recognize them being closely intertwined with IO and resembling weight based control mechanisms, and rather blindly copying memory.high/max behaviors, for which, btw, individual configurations may make sense. Thanks. -- tejun