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 E7DD0C54798 for ; Tue, 27 Feb 2024 09:15:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7AB8C94000D; Tue, 27 Feb 2024 04:15:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 75A4A940008; Tue, 27 Feb 2024 04:15:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D62294000D; Tue, 27 Feb 2024 04:15:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 497DE940008 for ; Tue, 27 Feb 2024 04:15:26 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6D6DA1C01E1 for ; Tue, 27 Feb 2024 09:05:28 +0000 (UTC) X-FDA: 81837000336.02.E57FCD3 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf29.hostedemail.com (Postfix) with ESMTP id 1D78A120016 for ; Tue, 27 Feb 2024 09:05:25 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=lPNXofkp; dkim=pass header.d=suse.com header.s=susede1 header.b=lPNXofkp; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@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=1709024726; 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:in-reply-to:references:references:dkim-signature; bh=SdG4cvaKZaOFuSXzq6nkBt+L7LnbypYQwZ3lNEASDmg=; b=NggP1aN/8sZVHm7Itfm784jfGOaByJ3XOU/jWs0sNTqSEQQer5AggYee/XDDUHy/sHXbOW gbUR4aKSv1vnfKbi3nw7uUmdasjZO5PAn0w5h2hPny/A0O+GSNkE+FC4I72AC7gA9+faDc p6xiVVOV8tegeit7j7ggDPSoCYTInNo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709024726; a=rsa-sha256; cv=none; b=cUvXdXk+WPtyy6pQOqV/2BjbsJdt3ExG3qIl+CXFrzPJA86Mg92J7lk0ep5BuSbidF1iU3 WSY3tzd+XJey0U2AmAWRHxXzGHy7Juz58GTQzOkjIa4tEkAxS8Ve2KP74VhKhtGYTIOdM9 OOBpEXg5zkUhKsqMsdFsX/OWIbGwuq0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=lPNXofkp; dkim=pass header.d=suse.com header.s=susede1 header.b=lPNXofkp; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [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 1936222778; Tue, 27 Feb 2024 09:05:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709024724; 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: in-reply-to:in-reply-to:references:references; bh=SdG4cvaKZaOFuSXzq6nkBt+L7LnbypYQwZ3lNEASDmg=; b=lPNXofkp9xjm1vo8ncAvKalLG64msx+GeghR2HF6DUfAzb5Cp4cVHitPIUgL3rSYuwJ4gw IUqndx5rF3kNZVNLB7+Q327rwTT9rHIdMPDL12TlTgE555tyefSKMbtTRoi8rQ40+s4b1T 61AKWa48Bm7E1vJU5XrnekcM+N+88UQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1709024724; 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: in-reply-to:in-reply-to:references:references; bh=SdG4cvaKZaOFuSXzq6nkBt+L7LnbypYQwZ3lNEASDmg=; b=lPNXofkp9xjm1vo8ncAvKalLG64msx+GeghR2HF6DUfAzb5Cp4cVHitPIUgL3rSYuwJ4gw IUqndx5rF3kNZVNLB7+Q327rwTT9rHIdMPDL12TlTgE555tyefSKMbtTRoi8rQ40+s4b1T 61AKWa48Bm7E1vJU5XrnekcM+N+88UQ= 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 1067313A58; Tue, 27 Feb 2024 09:05:24 +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 kYUkBNSl3WXSbAAAD6G6ig (envelope-from ); Tue, 27 Feb 2024 09:05:24 +0000 Date: Tue, 27 Feb 2024 10:05:19 +0100 From: Michal Hocko To: Yafang Shao Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, linux-mm@kvack.org Subject: Re: [RFC PATCH] mm: Add reclaim type to memory.reclaim Message-ID: References: <20240225114204.50459-1-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: 5it11hsuper66nkjf5oj9qijkh36kfbm X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 1D78A120016 X-Rspam-User: X-HE-Tag: 1709024725-429753 X-HE-Meta: U2FsdGVkX19VDRljdzP69G89L+xAxj+NPDWhPRR9p4bLt0nnGWXJoIh+tXqC/oMwlgGlGx4vL9oU16hn8eFQioc/7UHkQKvkwQBfF9UN8z8qkCUSll6G+tvOrHgbadfc3YakFgGoOdq3joWjkylOQZQfMMo4zE9FVQ/VlLFtnf3IEVLAJKuPAQVzZZWE2fpQb1WrNGAgYhIY0ONuIDZ20L6bzs6PeGQCM17extYEU/usikfVEUZpI/RYgVIy4pb00R+W18bVWNhU8NnVQ8cWfg1UFljfFhhaPmleGwdcLqTeFASCzBNeEp4BZas8UaahfFTq6BBOWblysW1beenWOZRCjIqOH+7SxaoMx4jqjtgB3VudyHa7W53EiFUKXOtfhw4sQDjTYLctLQemPpIESFicpmIBt+TAfQhTljpPIlEPJZbbxEWr0MLfitJuRo1NXzKZ1SMHuDsiBLvKJX3zDE2TglXVMSWxVoLIkwj7GeIpNfvjLUAwS+k2lNLenDddHdOszxAh3zAWh+OuT7YK2/uuae/4Hoy/Wi+KJucJU51wCUa/tsc8m8vNNWNSotzVDPrZvxuGkeBIYAo4gLbH9LisS9fIc3avfMczP5IFOaxCoyRPDuixWH8nPzb0GTgLS8O0lfxcKo1BtTEV4eFbgm8rFHE8GKLiF1I6mo4LgvUWhShWHcRvZa3NqgvqEF9PzA+pzMDOxDxShQhG7/SLsmBprjh8x+vrf2elhgM2QPq/BFkKo4mgvusK8t6X+pAKqiG5wvxFeEGXlplCe2IUVh3fNolHbvjSPG5IdHTmI2PaXWqyoPQlCRTVE4FDNFMO/TwIhKkPa92N4Q2rp36LBOHLujUAgu4w26heYIT/NVMBu34yyF5V/8lCHJFLvpYUK0DZHQsU7OXyNu8DlmqRI65fTEHCyMVwAWQwsjc9i0yvFNmkZOHm7lw/DwCcziBwQKe4E2NAc2Argpk+Xle aRG6UaEW p6bAXLokewqLOg1Pxq8mVdjq1HakJ+XhwT/j4RbsROsDKzoiz5+7LN2sIxXjkHbRuGKjfcX+31M1B8fVJ8DhlXIoZXL7Db0KY+scJWb0ZqbRaTfkdEueNBcEVygN/5D7UazlZ2V2RXGhfHV/NvRpXpZmulRaBAoK9cBhFLMHygKAQUVg660CkRgGfQHvrTOh8xTgeH4BYaMAH/QRms/VC2D32+rT/9em9XZhi1rN5rQdk/XXIYFvBwY9YSjAdAUYfu1uSAhXDdJ3qVAb2zd2WMPk4Dm2+b7la+6MEFe9Jd8TUbSuVcOvmoPGq8Z/zVqRqFgsCwXpFlC+gxxrkdhGHWJYEKqmAcbzigoUO2kAfdzk8gXI2+P+aZV4N0Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue 27-02-24 13:48:31, Yafang Shao wrote: > On Mon, Feb 26, 2024 at 10:05 PM Michal Hocko wrote: [...] > > > To manage disk > > > storage efficiently, we employ an agent that identifies container images > > > eligible for destruction once all instances of that image exit. > > > > > > However, during destruction, dealing with directories containing numerous > > > negative dentries can significantly impact performance. > > > > Performance of what. I have to say I am kind of lost here. We are > > talking about memory or a disk storage? > > Removing an empty directory with numerous dentries can significantly > prolong the process of freeing associated dentries, leading to high > system CPU usage that adversely affects overall system performance. Is there anything that prevents you from reclaiming the memcg you are about to remove? We do have interfaces for that. > > > To mitigate this > > > issue, we aim to proactively reclaim these dentries using a user agent. > > > Extending the memory.reclaim functionality to specifically target slabs > > > aligns with our requirements. > > > > Matthew has already pointed out that this has been proposed several > > times already and rejected. > > With that being said, we haven't come up with any superior solutions > compared to the proposals mentioned. > > > Dedicated slab shrinking interface is > > especially tricky because you would need a way to tell which shrinkers > > to invoke and that would be very kernel version specific. > > The persistence of this issue over several years without any > discernible progress suggests that we might be heading in the wrong > direction. Perhaps we could consider providing a kernel interface to > users, allowing them to tailor the reclamation process based on their > workload requirements. There are clear problems identified with type specific reclaim and those might easily strike back with future changes. Once we put an interface in place we won't be able remove it and that could lead to problems with future changes in the memory reclaim. -- Michal Hocko SUSE Labs