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 C6CA8C3B189 for ; Thu, 13 Feb 2020 15:47:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C8B820675 for ; Thu, 13 Feb 2020 15:47:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C8B820675 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 3AF8F6B055F; Thu, 13 Feb 2020 10:47:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3385E6B0561; Thu, 13 Feb 2020 10:47:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 200966B0562; Thu, 13 Feb 2020 10:47:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id 042736B055F for ; Thu, 13 Feb 2020 10:47:34 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A6C7D1EF0 for ; Thu, 13 Feb 2020 15:47:34 +0000 (UTC) X-FDA: 76485533628.10.year28_7c4ada2e90141 X-HE-Tag: year28_7c4ada2e90141 X-Filterd-Recvd-Size: 4615 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Feb 2020 15:47:33 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id p17so7302279wma.1 for ; Thu, 13 Feb 2020 07:47:33 -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=5uXyT83XmwzqIv81PcbryxoH+hy+LWMbBfLl6tfeT00=; b=N4chhGA6HRKoAqg8Avrq0mzYvakbdUicOP3eRhbc+jDN2xHLByvSimUdXAzwiM8hL9 1Mx7J5NnYmudZ+vss3KLw6h6v4O4P/PfOb79iRfumZQ5jPtQcS//GsRRZbeVUjujBEgp clfjakOKfG6gcy0+qf5SxVWq0IzYBYtC/qpZYZ4yLcbssGW7s0S+AuvWOaN9XqygV4Al qi/3czbDR0DXLb+MfrmRvNCaT+LUfg08Q6VBotD4hq8xgtivEK9IsdSXlpXt5SFZ8h8h f/Cv7zuXl8UvNcQrY/FV8TG9CvJvI68f8US1RdhMAK/5X7A8JCNM5qtUCX7mgJN2I43w 5hYw== X-Gm-Message-State: APjAAAUTG0rCJyXuitySbT/8/TKZtnOAjDt1boHuCWHeMNxCaoPEcouB OKZJScm6/z3b7u5FIRiYfiU= X-Google-Smtp-Source: APXvYqySk5ibJ4zkMSmy5HjIdccuefOJG5Dt7qTPHsKlLzNxOGy6HMI9u8O36DZcSV4dUIWKcQ6T5A== X-Received: by 2002:a1c:9c4c:: with SMTP id f73mr6215705wme.125.1581608853032; Thu, 13 Feb 2020 07:47:33 -0800 (PST) Received: from localhost (ip-37-188-133-87.eurotel.cz. [37.188.133.87]) by smtp.gmail.com with ESMTPSA id s8sm3464724wrt.57.2020.02.13.07.47.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Feb 2020 07:47:32 -0800 (PST) Date: Thu, 13 Feb 2020 16:47:31 +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: <20200213154731.GE31689@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> <20200213074049.GA31689@dhcp22.suse.cz> <20200213135348.GF88887@mtj.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200213135348.GF88887@mtj.thefacebook.com> 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 Thu 13-02-20 08:53:48, Tejun Heo wrote: > 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. Well, I would tend to agree but I can see an existing cgroup hierarchy imposed by systemd and that is more about "logical" organization of processes based on their purpose than anything resembling resources. So what can we do about that to make it all work? -- Michal Hocko SUSE Labs