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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39592C3DA4A for ; Mon, 19 Aug 2024 16:42:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C73CC6B0088; Mon, 19 Aug 2024 12:42:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFD1D6B008A; Mon, 19 Aug 2024 12:42:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A76B26B008C; Mon, 19 Aug 2024 12:42:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 85EB36B0088 for ; Mon, 19 Aug 2024 12:42:11 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2D62C812C9 for ; Mon, 19 Aug 2024 16:42:11 +0000 (UTC) X-FDA: 82469562462.25.167BBCB Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf05.hostedemail.com (Postfix) with ESMTP id 2116810000A for ; Mon, 19 Aug 2024 16:42:08 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="Np/p2DK9"; spf=pass (imf05.hostedemail.com: domain of mkoutny@suse.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724085651; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=J254iZqXeFW/IBKY25JGG4mlNXWPaB3teDZSrFqr5/M=; b=iviHU23j1CekIiRWzODxnoxDvcwoTsxtrX8DSoIOH5wQRljD2MIgIAOT6JfXrEtAdoBaUI 7blXX5zmQTn/xGWquUYr6lOJ7aFX4jR/YTDJ6ekSDQhpuaAVL2WYt8utBX1iDyX5BJhmI5 JGzlZPA2AM1DXC6oybtq7sA9jQ0+5iw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724085651; a=rsa-sha256; cv=none; b=6k/LxHVmjZlcgAKBG3kJEpnQulElfrcnP8xJezh5bwp+WiZdL4ex8OuI9M2dFCbSggpMzg 9oVMha2Dw34G7c8QIpXDWKcMLvbq6u/+tb1xYKlXDHetnfIfmtALySE6CRqzfAu+/CbxLT DU8gEBYbjGzTT9h/v3xhhzrjOucSWyc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="Np/p2DK9"; spf=pass (imf05.hostedemail.com: domain of mkoutny@suse.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a7a83a968ddso530694166b.0 for ; Mon, 19 Aug 2024 09:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724085727; x=1724690527; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=J254iZqXeFW/IBKY25JGG4mlNXWPaB3teDZSrFqr5/M=; b=Np/p2DK91gCOUCvtVkA1mqffZ9yzhzMrTvu8ZIQV3h+4Df3eFsfcUhErZKzVzC5W9N uSY7sICxl1CyiKaVQNgPgXaP2o+0rAOPO0T9ZoEsaU5JnelJU5vcr041hOAEOtUTdYWj 7wZ1PO0OgzerO7oAs8FbAwgcU0RMe9jKcMzyG1xnlBeaFiGO1GFHXm+UeLLN9JP4RLDW 0aefhDRSSg4UcDhHTE5M3i8bOVHxvLgIAYPrUAl70kTDl19S88D+L0fhGsElXmwKmU6j W67YDDvsIiXHvY07j/rG7O2ixfBEUZeMJA1N6F/zq10dMql/m3BGbKiuVywbG5KHwfy8 guPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724085727; x=1724690527; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=J254iZqXeFW/IBKY25JGG4mlNXWPaB3teDZSrFqr5/M=; b=DTeOHoyP1GqHh3d7IBSB1Q1OlzVmpbgsyN7cAiwoGS5BWgnc/Qo59AVcx/vfNW0Zql Exg/b6NiobDJIyjVAS2LvDiIvJZs+hbTRKx7qiHe9iFDkDzLeEAbPGIvOxtfWZvY0YJI /g56dE9KFDJmQa1DYxrnvCelk7100GqIlG8iKQ4UfkP0M9rRPxrG6Bk9R+1QO8RLKS8l CW3AmghgyrIiP1MtSWAqAcQnwbjlFMGrylaIV8dqtMLwf6N0meFj1a7zr+9M0IL4hvFX Z663/UbzkXNXqBXTnyQVqsXmFfKo3Lvy7oZuWRclcN/+ItGsfBvlSWkJCdTZW5aVFwTm y8ew== X-Forwarded-Encrypted: i=1; AJvYcCXdn1xOWFXTrptP8Fel1HJKDqvm63YLf+gx8aD7HQL8iqTZXQgGzGDSRDnjW2UvEwicIPBQMpmGkw==@kvack.org X-Gm-Message-State: AOJu0YzSw6AcS4UXCekxosledF568qlmwxlxT5UGvL+bE4Kqou3Inych VG+Epri0tGxu7/s6Howg048vOIRXB2mo++V5IDv1BTSW4ekSLM6g/ymGckxsTIo= X-Google-Smtp-Source: AGHT+IGc7Y3MmAAzORrqsNcvCCVwaOSb2DMB3HTVCcr73ggR8XtsJqc9A/JZXNE6KY6OjUJc51XmJA== X-Received: by 2002:a17:907:e2a5:b0:a7a:9f0f:ab18 with SMTP id a640c23a62f3a-a83928d7b9emr751698066b.20.1724085727388; Mon, 19 Aug 2024 09:42:07 -0700 (PDT) Received: from blackdock.suse.cz ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a83838cfd5esm653486366b.78.2024.08.19.09.42.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2024 09:42:06 -0700 (PDT) Date: Mon, 19 Aug 2024 18:42:04 +0200 From: Michal =?utf-8?Q?Koutn=C3=BD?= To: Jan Kratochvil Cc: Roman Gushchin , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Michal Hocko , Shakeel Butt , Muchun Song , Andrew Morton Subject: Re: [RFC PATCH v5 0/3] Add memory.max.effective for application's allocators Message-ID: <7chi6d2sdhwdsfihoxqmtmi4lduea3dsgc7xorvonugkm4qz2j@gehs4slutmtg> References: <20240606152232.20253-1-mkoutny@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3qoufy47xt4jaygv" Content-Disposition: inline In-Reply-To: X-Stat-Signature: 5fn1bwc5c65n5bubb4djzpue93kszoyf X-Rspamd-Queue-Id: 2116810000A X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724085728-177061 X-HE-Meta: U2FsdGVkX19cGPFb4l39kTi7vQNNRBAajQAA2EKAOt+Bvdx8vO4HqorFbz/f3MbX0XFSoyFA6KsxLunPBeTrMaoP/HcEdbAXHhrad7uu2eYFU1rz2pZJCA2D2fxh5o6ySvRy+ux4KkmluxcaLbGq9dW2PIW6DDMjAT+iQsbX7wYnUhf6bE0Clmp1CjKf8tRpuqCrW1RcGT5YGgAmfQNpEjzeolwDNYKlflkcE4WICdXX+eRX0KcFlTmw6IKdho0Lhuqshn6OBrQtwzVh1yiKQUuecUF2iz+zkdnJKFIbEfvcN+Y2/PpFW41Mm6ZGIE4LuLiQ3e6jf2AVxeoycNIZnzU6Ezb/+r++Ftv5r3WcwPjA5lXbv9HzsmtXYLE8org9Fuy8WfI5akABaJQMxbUN/AA3BA0YwqMbq6ciRLwyN54qYjuJjFFD/w8Pexh/Aetrxby4lQAqb7j23DSkDZljDJkg3rvYhvSZvRfcAhGQGIpooYcu1mNj/Dg+61ecYr7EaLmsvAViW/+Utw5NrvIMin3okRyU3yin1DpWF4fwnL/LWcdno94wyFS7s+qwrKbDw1ZNdTHc8CX8tuDLD7nK+s8I2bddLA/KBZEIivmERD7gW4FNAwBox0DGnJwC9FDfbUh2BsfdcoqRRqujkrgVQ3ckyeJJaMBwsrrqsjrx4C7PqqhOqdD4/Vvn2kZkigo8BBvXiOlf/+Purh+LIfiVfdAYp0+dCSv23aiTsTIBS/zUk3u2OnqmRiAJeopP2dZrUK2S1B1tHjfOnoRr7kcwq0yZ5sWxWtEhvZPyDv9sBjAJ6huvXwgFmTOqFZxmPJMoqB+h7B5rGcy7MfxhHDHPIfLz6ROLmVxgIfCgCLRq8ZxJHjNdxwm0iFRQ1D9xqzSeqZOj+WJYYHcqDXVPhrHq808re9MXwlp3vnHJ1bahQd/ayRuYtv84hlGUT5X7x99KaABjQsgrsiffk6gKlxp fBLxCf3+ WHBPIKVOdBlzHi+gCV7mMwyQdJUp1RFs8ZgqjB6W/ppIw3uO3eNj79ECyMgU9iE0cSJMJ3LkTwieTNPCQ0lau9ZLhPShi9n3t90LM2C65sc//9yU/EH2V0a388i7j6Za6zS+3KydeKngc4HAn3q8ezIKHEAYBtdHgawFCieroSAdpNTDJECSXIxSeHJAHdSuX4stASY5nlIvbX3PLICBufemocYn5HA4HqHDztcHYO3/F5jUL9XjrsGXTO0YD5/yyMsH8mEJeNYuZw6uuZqkk5KL3sIzjQO027YKDssoiY+AcNhOSyFIcM3z0p17QDI17tlWtMyoIuTIv20ONFpU4K98mYCjjQ4UdPPBu7i10Df+kcficFQdgSAYqwwSK7FZmojeKq+rK7SlPS14f1YoR8fjyiQsR9qD26hWP8MVSY9dfrjCxrqvoUT1/sbkSvm+iqSCnRrzf/VY74+TpZU1F6s4t3NsxdGSAsEhGyCQrgAtoUAiSoS7rocyc92h4/Ldja1SoQi9hJRyzLGza+ql8ECex538YE2FrCU7qnfQw+S/4ja8= 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: --3qoufy47xt4jaygv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello. On Sat, Aug 17, 2024 at 02:00:15PM GMT, Jan Kratochvil wrote: > Yes, it would be better to subtract the used memory from ancestor (and thus > even current) cgroups. Then it becomes a more dynamic characterstics and it leads to calculations of available memory. I share a link [1] for completeness and to prevent repeated discussions (that past one ended up with no memory.stat:avail). > The original use case of this feature is for cloud nodes running a > single Java JVM where the sibling cgroups are not an issue. IIUC, it's a tree like this: O / | \ A B C // B:memory.max < O:memory.max | ... | W // workload This picture made me realize that memory controller may not be even enabled all the way down from B to W, i.e. W would have no memory.max.effective, IOW memory.* attribute would not be the right place for such an value. That would even apply in the apparently purposeful case if there was a cgroup NS boundary between B and W. (At least in the proposed implementation, memory.* file would have to be decoupled from memory controller, similarly to e.g. cpu.stat:usage_usec.) Jan, do I get the tree shape right? Are B and W in different cgroup namespaces? Thanks, Michal [1] https://lore.kernel.org/all/alpine.DEB.2.23.453.2007142018150.2667860@chino.kir.corp.google.com/ --3qoufy47xt4jaygv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTd6mfF2PbEZnpdoAkt3Wney77BSQUCZsN12gAKCRAt3Wney77B SfKMAP98Nu9R8Ci7oQVELkl/Cc/lz32Tor3WKf6p5MrrV1/TiQD+OChE9aRronRA cPrXjYdbqUEGMJBtWaysDMAsNAK9kAo= =izr6 -----END PGP SIGNATURE----- --3qoufy47xt4jaygv--