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 D68F2C35642 for ; Fri, 21 Feb 2020 10:11:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 91FC120722 for ; Fri, 21 Feb 2020 10:11:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 91FC120722 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 31F826B0003; Fri, 21 Feb 2020 05:11:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D05A6B0006; Fri, 21 Feb 2020 05:11:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BF6F6B0007; Fri, 21 Feb 2020 05:11:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id 046A26B0003 for ; Fri, 21 Feb 2020 05:11:50 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 96227249D for ; Fri, 21 Feb 2020 10:11:50 +0000 (UTC) X-FDA: 76513717980.15.pail77_84718e0dbb243 X-HE-Tag: pail77_84718e0dbb243 X-Filterd-Recvd-Size: 6999 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Feb 2020 10:11:50 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id q9so1087733wmj.5 for ; Fri, 21 Feb 2020 02:11:50 -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=6zP/5ARV9Z0j3qqlT+U93tg/6H0b/blVsI4MpzZxVfM=; b=BVE3FqvYB7JdunaPglLczS5lvGMoffOoSozcSaTgkAHFdNSMNIC3xcC1ktp3E9tmge McZ9ZaIqVuK2+kfs0fMvfWP+eVtDNpY2aoDMwviUwGn6H7hIYrvBmdilRJCHg3pew7kn VKc2lk/tHCSdQO/5T/mjcltRoY4fMuV7WOKzIaiAjR1pxbc00W/Z+1OYOBJRkbCA9aik Fe7O3x9WU9oz/TW2fYwDaWHwSSvfU06qpLUvIJ2ABaojzJPIkJwLkUh9YGX7h/Vq8EbY kGzXcLiK98fhaUQtccQH96Uk76qq5no1lz8+6W1n09zYjGw8rmUJCGuf/hj4iGIKEP02 YwGw== X-Gm-Message-State: APjAAAWmPPjeh5Ld+uPLG3GWjmJv8DoOtKXA+wuKCGohufQ3gAwgrE1D WkrQDjzMgQKNkWfyI9OzK4I= X-Google-Smtp-Source: APXvYqyGH7jwWXt/GPQ821RP3ryu7W+8ERCfEaKJ0x9dVQFNTZpaswY9yzL4ZQ/qO357BQ/1DcPGvg== X-Received: by 2002:a1c:bdc5:: with SMTP id n188mr2857996wmf.124.1582279909011; Fri, 21 Feb 2020 02:11:49 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id 59sm3592478wre.29.2020.02.21.02.11.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Feb 2020 02:11:48 -0800 (PST) Date: Fri, 21 Feb 2020 11:11:47 +0100 From: Michal Hocko To: Johannes Weiner Cc: Tejun Heo , 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: <20200221101147.GO20509@dhcp22.suse.cz> References: <20200213154731.GE31689@dhcp22.suse.cz> <20200213155249.GI88887@mtj.thefacebook.com> <20200213163636.GH31689@dhcp22.suse.cz> <20200213165711.GJ88887@mtj.thefacebook.com> <20200214071537.GL31689@dhcp22.suse.cz> <20200214135728.GK88887@mtj.thefacebook.com> <20200214151318.GC31689@dhcp22.suse.cz> <20200214165311.GA253674@cmpxchg.org> <20200217084100.GE31531@dhcp22.suse.cz> <20200218195253.GA13406@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200218195253.GA13406@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: [Sorry I didn't get to this email thread sooner] On Tue 18-02-20 14:52:53, Johannes Weiner wrote: > On Mon, Feb 17, 2020 at 09:41:00AM +0100, Michal Hocko wrote: > > On Fri 14-02-20 11:53:11, Johannes Weiner wrote: > > [...] > > > The proper solution to implement the kind of resource hierarchy you > > > want to express in cgroup2 is to reflect it in the cgroup tree. Yes, > > > the_workload might have been started by user 100 in session c2, but in > > > terms of resources, it's prioritized over system.slice and user.slice, > > > and so that's the level where it needs to sit: > > > > > > root > > > / | \ > > > system.slice user.slice the_workload > > > / | | > > > cron journal user-100.slice > > > | > > > session-c2.scope > > > | > > > misc > > > > > > Then you can configure not just memory.low, but also a proper io > > > weight and a cpu weight. And the tree correctly reflects where the > > > workload is in the pecking order of who gets access to resources. > > > > I have already mentioned that this would be the only solution when the > > protection would work, right. But I am also saying that this a trivial > > example where you simply _can_ move your workload to the 1st level. What > > about those that need to reflect organization into the hierarchy. Please > > have a look at http://lkml.kernel.org/r/20200214075916.GM31689@dhcp22.suse.cz > > Are you saying they are just not supported? Are they supposed to use > > cgroup v1 for the organization and v2 for the resource control? > > >From that email: > > > Let me give you an example. Say you have a DB workload which is the > > primary thing running on your system and which you want to protect from > > an unrelated activity (backups, frontends, etc). Running it inside a > > cgroup with memory.low while other components in other cgroups without > > any protection achieves that. If those cgroups are top level then this > > is simple and straightforward configuration. > > > > Things would get much more tricky if you want run the same workload > > deeper down the hierarchy - e.g. run it in a container. Now your > > "root" has to use an explicit low protection as well and all other > > potential cgroups that are in the same sub-hierarchy (read in the same > > container) need to opt-out from the protection because they are not > > meant to be protected. > > You can't prioritize some parts of a cgroup higher than the outside of > the cgroup, and other parts lower than the outside. That's just not > something that can be sanely supported from the controller interface. I am sorry but I do not follow. We do allow to opt out from the reclaim protection with the current semantic and it seems to be reasonably sane. I also have hard time to grasp what you actually mean by the above. Let's say you have hiearchy where you split out low limit unevenly root (5G of memory) / \ (low 3G) A D (low 1,5G) / \ (low 1G) B C (low 2G) B gets lower priority than C and D while C gets higher priority than D? Is there any problem with such a configuration from the semantic point of view? > However, that doesn't mean this usecase isn't supported. You *can* > always split cgroups for separate resource policies. What if the split up is not possible or impractical. Let's say you want to control how much CPU share does your container workload get comparing to other containers running on the system? Or let's say you want to treat the whole container as a single entity from the OOM perspective (this would be an example of the logical organization constrain) because you do not want to leave any part of that workload lingering behind if the global OOM kicks in. I am pretty sure there are many other reasons to run related workload that doesn't really share the memory protection demand under a shared cgroup hierarchy. -- Michal Hocko SUSE Labs