From patchwork Fri Dec 13 19:21:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Weiner X-Patchwork-Id: 11291521 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1FF8B139A for ; Fri, 13 Dec 2019 21:28:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 92C7224125 for ; Fri, 13 Dec 2019 21:28:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="wgSZLGRU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 92C7224125 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 B52988E0014; Fri, 13 Dec 2019 14:22:08 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id B03F08E0001; Fri, 13 Dec 2019 14:22:08 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1A5C8E0014; Fri, 13 Dec 2019 14:22:08 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id 8A5E78E0001 for ; Fri, 13 Dec 2019 14:22:08 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 4960D82499A8 for ; Fri, 13 Dec 2019 19:22:08 +0000 (UTC) X-FDA: 76261088736.09.can60_8700a9ece2a5b X-Spam-Summary: 2,0,0,9eee0bb694340b95,d41d8cd98f00b204,hannes@cmpxchg.org,:akpm@linux-foundation.org:mhocko@suse.com:guro@fb.com:tj@kernel.org::cgroups@vger.kernel.org:linux-kernel@vger.kernel.org:kernel-team@fb.com,RULES_HIT:41:69:355:379:541:966:973:988:989:1042:1260:1311:1314:1345:1437:1515:1534:1541:1711:1730:1747:1777:1792:1801:2196:2199:2393:2559:2562:2693:2897:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3872:3874:4250:4385:4605:5007:6119:6261:6653:6755:7903:10004:11658:11914:12043:12219:12297:12438:12517:12519:12683:13069:13161:13229:13311:13357:13894:14096:14181:14384:14394:14581:14721:21080:21444:21627:21740:21772:21810:30012:30054:30074,0,RBL:209.85.222.193:@cmpxchg.org:.lbl8.mailshell.net-62.14.0.100 66.201.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:25,LUA_SUMMARY:none X-HE-Tag: can60_8700a9ece2a5b X-Filterd-Recvd-Size: 4621 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Dec 2019 19:22:07 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id z14so108860qkg.9 for ; Fri, 13 Dec 2019 11:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Md8aPp7pWyGuw5IIpUNdRQgPAvuPZuMepp2Ahz2Nx4M=; b=wgSZLGRUOXwzFB4dfBnzTeSU23C7S7RRsjtSNusnCzXmKwnqrtYtHchbbxHW6dqapq MjghPETHNvKrpaC4P42jqcAt5wpcqzU0OADzTYo1e7xY99FcQTby3wlOrGvEBtpkc3L2 6G0T1SS8d+6LQjg38Y2yKe6cLvZylqzSJ+aEhVQjCpBshBp3/jeI6QsuKw3DcOyxqTBC MsKge1RHa22f8HtCjtNI02qMb+YOCDmCOgVfeMTTv/2eA/4D6h9d1lEZPJxI6dUoIiQa sp8jbhVfvh+id58flVOEQZM5L+C5XnCBhhgjSG85RPGD9hI6Pm1nbl37bI40mNck5b3M gQpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Md8aPp7pWyGuw5IIpUNdRQgPAvuPZuMepp2Ahz2Nx4M=; b=rISc7rcSp5AFY271I02C6IuyEVPCVathXfCdRzOdafccG6ORumWFmRqWyz+iNw6Y8F hxhqNQoPkgUXXBVG8qEA6IB+ZB6if+/EtHRZl74CHPgcRPxIk3ndCsMVJ7VAeDmg9tvf oDEeasZZgPh5gSQvlqWuQ/k2l26xdRwwn3nvkFbVrFQIDzt6cjW4PjR1vuVghdAaHoBw 5liJ7YTkzLlC2i1FCNno6oWvYGRG1yWMAbAeZVFDeJx8xXDflyLVu2sA3NL7CiO5W61r D2Z+eRJwQuRSfcmNQQBYRBTXEo3C98nV82RY2Ou3IhYvZwTNHun94hs0I0A+hemuwgZ4 xaLg== X-Gm-Message-State: APjAAAU68DsoCwVPCzha86qvFrjjAFmKKFou1eko9W9Teicss03IWWWb IwzrNEncgo9GtjJyp02Bp5XEng== X-Google-Smtp-Source: APXvYqw3FXp7YEWHaxT92Q3RIcSBkI/2b737GDnuzflnKDpEga0bi1FPxsejP17D7pOITWtyao4ogA== X-Received: by 2002:ae9:c112:: with SMTP id z18mr6555577qki.145.1576264926538; Fri, 13 Dec 2019 11:22:06 -0800 (PST) Received: from localhost (70.44.39.90.res-cmts.bus.ptd.net. [70.44.39.90]) by smtp.gmail.com with ESMTPSA id c37sm3735674qta.56.2019.12.13.11.22.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Dec 2019 11:22:05 -0800 (PST) From: Johannes Weiner To: Andrew Morton Cc: Michal Hocko , Roman Gushchin , Tejun Heo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 0/3] mm: memcontrol: recursive memory protection Date: Fri, 13 Dec 2019 14:21:55 -0500 Message-Id: <20191213192158.188939-1-hannes@cmpxchg.org> X-Mailer: git-send-email 2.24.0 MIME-Version: 1.0 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: The current memory.low (and memory.min) semantics require protection to be assigned to a cgroup in an untinterrupted chain from the top-level cgroup all the way to the leaf. In practice, we want to protect entire cgroup subtrees from each other (system management software vs. workload), but we would like the VM to balance memory optimally *within* each subtree, without having to make explicit weight allocations among individual components. The current semantics make that impossible. This patch series extends memory.low/min such that the knobs apply recursively to the entire subtree. Users can still assign explicit protection to subgroups, but if they don't, the protection set by the parent cgroup will be distributed dynamically such that children compete freely - as if no memory control were enabled inside the subtree - but enjoy protection from neighboring trees. Patch #1 fixes an existing bug that can give a cgroup tree more protection than it should receive as per ancestor configuration. Patch #2 simplifies and documents the existing code to make it easier to reason about the changes in the next patch. Patch #3 finally implements recursive memory protection semantics. Because of a risk of regressing legacy setups, the new semantics are hidden behind a cgroup2 mount option, 'memory_recursiveprot'. More details in patch #3. Documentation/admin-guide/cgroup-v2.rst | 11 ++ include/linux/cgroup-defs.h | 5 + kernel/cgroup/cgroup.c | 17 ++- mm/memcontrol.c | 241 +++++++++++++++++++----------- mm/page_counter.c | 12 +- 5 files changed, 190 insertions(+), 96 deletions(-)