From patchwork Thu Jun 6 15:22:29 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Michal_Koutn=C3=BD?= X-Patchwork-Id: 13688668 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B5A9C25B75 for ; Thu, 6 Jun 2024 15:22:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77FA46B009D; Thu, 6 Jun 2024 11:22:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 72F6A6B009F; Thu, 6 Jun 2024 11:22:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F6A66B00A0; Thu, 6 Jun 2024 11:22:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 40E8D6B009D for ; Thu, 6 Jun 2024 11:22:46 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BB618C0724 for ; Thu, 6 Jun 2024 15:22:45 +0000 (UTC) X-FDA: 82200831090.22.44FE311 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf11.hostedemail.com (Postfix) with ESMTP id A42404000B for ; Thu, 6 Jun 2024 15:22:43 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=c52DHjTf; dkim=pass header.d=suse.com header.s=susede1 header.b=c52DHjTf; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf11.hostedemail.com: domain of mkoutny@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mkoutny@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717687364; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=NVBrEhkQ/SUTCVD/ZxuFTIDe7cANiTexdjnYFfXgLAA=; b=Y1oBMa2tJYSANl4muinQLvpVPWfnhfwPDkjClbXPYmcpXniuB39itR2/golDQlxpWWrQQU bGmQ7FIQvncz9+owobKcUcDKROF64SClADxxFR0BG1tVPq4HkYiXjg0WsZ7rFC442vDnM5 7k11GA5NTQtOhM1/6QjMLyGDOvw7Pj4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717687364; a=rsa-sha256; cv=none; b=fCxNMMe+UHp0rg1VzhuGjvkznU3L/JmYXYEws4ebeJpwxEJglGH2d4fgJuoAuj1fCYubo/ FTdFw369s/rJSULMGSy7XAtFYYd/0SMKb80beHrvIoVfbsUbxIl8jVNMdZsaUu+jiDxP3y mZ05mY+jR2OA9pWhmVRs/JkC2b7iYlU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=c52DHjTf; dkim=pass header.d=suse.com header.s=susede1 header.b=c52DHjTf; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf11.hostedemail.com: domain of mkoutny@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mkoutny@suse.com Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C7C942198C; Thu, 6 Jun 2024 15:22:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1717687361; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=NVBrEhkQ/SUTCVD/ZxuFTIDe7cANiTexdjnYFfXgLAA=; b=c52DHjTf3tz5dLkltT4ybFvvfqEqeP7VMxVhebZGrZjSxJZTqFA2ujwnKNLd3/PUd3aLWh fmdUzRrs+qpFz5x0C5YT2Nq+hT0dbUWCkoqFNMkU6lwUpZTyvMObCWR+daUXWP38DnSQsa kg2Fba2IanT4uhU1ZPr5hPAgPTSvYoE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1717687361; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=NVBrEhkQ/SUTCVD/ZxuFTIDe7cANiTexdjnYFfXgLAA=; b=c52DHjTf3tz5dLkltT4ybFvvfqEqeP7VMxVhebZGrZjSxJZTqFA2ujwnKNLd3/PUd3aLWh fmdUzRrs+qpFz5x0C5YT2Nq+hT0dbUWCkoqFNMkU6lwUpZTyvMObCWR+daUXWP38DnSQsa kg2Fba2IanT4uhU1ZPr5hPAgPTSvYoE= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B5ED913A79; Thu, 6 Jun 2024 15:22:41 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id Xy04LEHUYWbGbwAAD6G6ig (envelope-from ); Thu, 06 Jun 2024 15:22:41 +0000 From: =?utf-8?q?Michal_Koutn=C3=BD?= To: cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , "Jan Kratochvil (Azul)" Subject: [RFC PATCH v5 0/3] Add memory.max.effective for application's allocators Date: Thu, 6 Jun 2024 17:22:29 +0200 Message-ID: <20240606152232.20253-1-mkoutny@suse.com> X-Mailer: git-send-email 2.45.1 MIME-Version: 1.0 X-Stat-Signature: s9j19x5n16us935wqdsr5ueh8kpmnr59 X-Rspamd-Queue-Id: A42404000B X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1717687363-193741 X-HE-Meta: U2FsdGVkX191xYS89wRp+TdC11y3CtX9KeOZuZCBrNRKjU2wXwJJGjmT1hiWZcLWBzOdbzwHhAsgZUte8mLXQWYZW8Am32N+iD1GZyANpjV5ohdL4gBlScUsLuNTiV8EI4rZ/Y2M61obt0nuqz/LRGdEKFBwGUrwiauHBoeOL5nRjs8EpK1mVqSqZ6rBctH1TeDi4NPLzvE/xyfI3D5/xRa7M9CVJ0uawBAvmOyUFJ3Q/d/9AJjyDR+dnjGl92CXcU/AJ8l4rJ6VUifJLp9yzUssAJuJtd8dNR4nmJNPLEsydRYiGb1H4SZp7RzJvGH6GI0BIUR/+8eQ6LLG2PLHlbU6/BCy9WphVnjDaXHsQmhtJGk3iIfZzEyip8O623X8hDNZBHqwQPB7i1WQLwdDJWC751tn0Q0FjAk4EpU4e9d4EzlYykQpirVDctaaccTxtN6UjLqafWV5JUPWt55mkZO8pYPTWn14ZmlqybfxRCppjFQ+DBryRK/RhVfkZ5t4jSu1P7GZidngrEzv96IFV0hqXSjlrps24amEcOaaRY6UgNuD5egw+HKcodt5B1u19KaOuO95lY5loXzut6c/DAA0/ge3XsrHTfuAKcfJeLs5ziHUbUFWO6b1izga2rX9ikdmHMM+h3sySg8LxPK4nEiinKh4R/StsUoaiJPM845U2YtaGjGYCOlNQVdFYSeOzwNL7mvnYsmVxHhgDOSm50nnmzdMzvevLvIH5lLVyAS8O9cwLFgIXiPdjvgAO5IUNa/IQv6aRaYuYvV5tqT6u66fS0nDzRSS0qybHva+s+vsY/IJvGkTbjN1sMQmKtqvxFaGu7aOU/xxL0JrXffhUIqKkDa5VZ5FULoFNR5UVRi6vhcoJcqkTR8NeaHjzbdwU2gqIEBhgOzdKUjFe5cT8OXGQsgh1RHbAdIspJLCKLhOluy43DmevYN6Os7rKF2uYkqBladvSHficAy5dw9 bbQM+Z5w kal7IJK37WaGif/X/iya5g5DnQGVaB4FcBXOAbrftlZHVfi++BJgn55usS8Ib4nSaxyc8Cc/VEkE1QNp5np1X2PwC34360xYlE+0Ho/BT3TJWTWNpBpHrFmNRlhl5JsuyWU29gSfoEfdgtnqbjpE3NVDe+bV9TqRqO7P5s1jziRW/AEv8x/Fy4f/klCVt7pOFA7N15BDsOEZsT9lAo36wre7L0Ddna3w3bQcnL2SvSjDWoUY9l2LRp2wkPJ/ipyMDPfy4bp68C2Nv8Fj6qabyPfUDVUyu0lrpx9QDDNzOJhbgrF/V9LFZFL/du0v7dUiNAtSg7weAwo671i4gCrXG0kZpq0uvF0R9NIImE0iaTkau//F8SwgTNYb3Jyg+9Xm/VsTNR0eBBOlcLec= 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: List-Subscribe: List-Unsubscribe: Some applications use memory cgroup limits to scale their own memory needs. Reading of the immediate membership cgroup's memory.max is not sufficient because of possible ancestral limits. The application could traverse upwards to figure out the tightest limit but this would not work in cgroup namespace where the view of cgroup hierarchy is incomplete and the limit may apply from outer world. Additionally, applications should respond to limit changes. (cgroup v1 used memory.stat:hierarchical_memory_limit to report the value but there's no such counterpart in cgroup v2 memory.stat.) Introduce a new memcg attribute file that contains the effective value of memory limit for given cgroup (following cpuset.cpus.effective pattern) and that sends notifications like memory.events when the effective limit changes. Reasons for RFC: 1) Should global limit be included? (And respond to memory hotplug?) 2) Is swap.max.effective needed? (in v2 without memsw accounting) 3) Should memory.high be also handled? 4) What would be an alternative? My answers to RFC: 1) No (there's no memory.max in global root memcg) 2) No (app doesn't have full control of memory that's swapped out) 3) No (scaling the allocator against the "soft" limit could end up in dynamics difficult to reason and admin) 4) - PSI (too obscure for traditional users but better semantics for limit shrinking) - memory.stat field (like v1 but separate attribute is better for notifications, cpuset precedent) Changes from v4 (https://lore.kernel.org/r/ZcvlhOZ4VBEX9raZ@host1.jankratochvil.net) - split the patch for swap.max.effetive - add Documentation/ - reword commit messages - add notification support Michal Koutný (3): memcg: Add memory.max.effective attribute memcg: Add memory.swap.max.effective like hierarchical_memsw_limit memcg: Notify on memory.max.effective changes Documentation/admin-guide/cgroup-v2.rst | 6 ++++ include/linux/memcontrol.h | 2 ++ mm/memcontrol.c | 46 +++++++++++++++++++++++++ 3 files changed, 54 insertions(+) base-commit: 2df0193e62cf887f373995fb8a91068562784adc