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 E6AD6C54798 for ; Tue, 27 Feb 2024 10:06:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38C5C8000E; Tue, 27 Feb 2024 05:06:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 33749940008; Tue, 27 Feb 2024 05:06:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B1AE8000E; Tue, 27 Feb 2024 05:06:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0544E940008 for ; Tue, 27 Feb 2024 05:06:45 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A6B7AA0FA6 for ; Tue, 27 Feb 2024 10:06:44 +0000 (UTC) X-FDA: 81837154728.29.E6EBEA7 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) by imf07.hostedemail.com (Postfix) with ESMTP id D9FD840012 for ; Tue, 27 Feb 2024 10:06:42 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=D6wN04Nm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.182 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709028402; a=rsa-sha256; cv=none; b=ZMq0h5bN/GxAPQ3RxWsrmsx4tQwXvYVCtJYJcGJgx1sj8eBSp/AuKrENUWR+LuhaX6li2f fTZEidWDNT2ntPRPWSh3QPfj8Oae7yO+kIb3pYnFl39OP2ZsjbrEQ/0UyYwTLHNGHW6kEi GbHrB1rH+29EnAx4NDnDXG5yikVTIcw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=D6wN04Nm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.182 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709028402; 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=SKjSODQKBY04yTQEmwatUS9jsWmnPFoGr5VVaI+bZpI=; b=arydcGm8yeDoaDQxEU0xDOoI+XHbgHXxkq2UI8NuD2O3my28hMF0ThXw1ZGFqLWwEx7/hw pqXJhZfRtOnf8KxRHnL8RoBnduYnVvKAfFtPJPS0XfWW9qDEn+EQ0HnCjHlPTsLW1m36jG zkc0/LWXJqoOIXYEbvVTLYxWUh6U0U4= Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-787b4d1393aso260498385a.0 for ; Tue, 27 Feb 2024 02:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709028402; x=1709633202; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SKjSODQKBY04yTQEmwatUS9jsWmnPFoGr5VVaI+bZpI=; b=D6wN04NmfrJ9ssgc9aseQ3sYCHpeGrmHsSGTGW8YZShfhFhktdqJvj9Y+CyYPTCNjY f6qc++An7Fyl8qyP9eI5l1TsqLJ9NnLXrIvhnQS7kS15+Zr+gK/AqhDmsU5StNzujxmv zhmL7UBX7j2jDHh21THD/4F1vPJcbiJgrcx/m08DGA7H3egpPo+tADcd4vku4xc/yKMG jHOzCQED0yEYstdDE/KDk2c957/ooEWfPLYlOjugc7xzKi1/nOAm+cqiQ79f3Y4OuWew djrd8GzQrvYnCaNw5iuziVybAUxzO6O3vmJKPfege4UwWQaBinlOuj1gF9BhjnLK0jWY h5yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709028402; x=1709633202; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SKjSODQKBY04yTQEmwatUS9jsWmnPFoGr5VVaI+bZpI=; b=Fw2WX+qkdjXDxHuSz3ajcFx6dML4DWWYzRtr3OlMT0S1D1IICaI/Ud/EDd+S9UWkv4 NM/P63RL+V3RZCThlL0fgxXhCYzg0s+P1Fa6l2F5h7TatviLZDiEkmzokli02C7sMEsV KAeARgNBJZfWQeyijr4NtgY9sU3OO66kNGP4bRHZFIuFD4sZbvzy6wbCt3pqo99DeA8K IbrbKMkvOBtStdh+C14VqpvhvHlsP/D0sMXrDdkXcrQMOuG+aY/Q1wUHX11iLDZCMBMw GpKmjnQiyvWVzKuBZ6z58ECQ/irBbsTcfqH3HctrIsXFw+n0dfFw4YcTxtzwQlLejiRF WiqA== X-Forwarded-Encrypted: i=1; AJvYcCUID6sCa7dkI1pQpiotfpgjxTRgNsD6eO/wN0bCj+sNAyHHoV3RR40jJzOexp0HdPHHTUxkz2VJbZMnf2KBgOH4e4Q= X-Gm-Message-State: AOJu0YyVhx6E/AiQPVhYwLSv/BeQtVIfvOOtlVJydudNmVX2WGyKZJlJ lG1ELTaM+Yc+XJb+luRAZGRj+676Sz5RjS2/XRREcUBb2gLBOSG+5uVrBV/KG2qLO1/WTo6lLso KN+kYQiGye3YhxwWCbZsFhVhT3pA= X-Google-Smtp-Source: AGHT+IGIDVC8V0YCO845mqd+V3TV8FJhhcNg1OtrweeKrStjC81uGS3jOSsjx9ycrRUXzo2g+cz7vLCh2IiKoPXj3/8= X-Received: by 2002:a0c:e1ca:0:b0:68f:e821:ed43 with SMTP id v10-20020a0ce1ca000000b0068fe821ed43mr1588404qvl.42.1709028402068; Tue, 27 Feb 2024 02:06:42 -0800 (PST) MIME-Version: 1.0 References: <20240225114204.50459-1-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Tue, 27 Feb 2024 18:06:05 +0800 Message-ID: Subject: Re: [RFC PATCH] mm: Add reclaim type to memory.reclaim To: Michal Hocko Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D9FD840012 X-Stat-Signature: cumrtsa1tpydk45kty48n9hmf9ydgaka X-HE-Tag: 1709028402-371044 X-HE-Meta: U2FsdGVkX19MFlMp5mxZzXqFT2pnOS6wDcfUOc9GweobV8Vxv+5zkMNdkkfMUXtsVF1UdPlj7sWwgxkORu/eK2yw4N2M2NAfdiDvxC32P5idSEXZoFfU94QOYcetUk3CcTunPv0TRNBGs82ECgotNxi8za3DHqUuiTYxyNyf/mHYcDd7Wyt7Mv7kw0A8Cgg49w8BknA581IbX7en+rEx1a9S8FloIw1VxXgpnh+OKoE4pFlJgPQxyr6ZOUMP/J7thESoWulICydYYcNNur/ODUBgwHr4zDUjuYWUunue5b24WITnSgOwzgSRhEqAt8Ojkj4D2EaAgpBRBbRBLrSw+oJLds2g9+gPQY0oH2mcnpOrBYsnFK80WoF9HDtMj+DDQ6nvr4u2YEAIyUGr6/lvmfbrckg5mgwh1lgI7rpG3+wpfkHG64GErdqtDAe18wIOeIGaf5WKYqgtCww2QhOKdHppHCYSpAtcjwpzY2hVrPwUqGiOve0Du/AWpf7zGxk9e6ztCLBhm4f3j1zhesUXBOIRnWoRJ2jb8WaCIcyaRHFmRjZTDIXeXAx9CDQEb93uNp6i2otNEuSQC8wHtbfMrdBHVE1QerFfF95oc9kmKA6q4TFcwBaslTWvXM+SFTRFuYUvbjhuzuhg9glSGJH9a66jPTltb7ImBeEnRpXUYU+zH0OPG1hKVl6D/1CHCwQlGZxFsdcsAVSZK9G/HuGcG0AcLZDlPPKsrJolPaDvTbOlyAj35zkiXvS+QFi2bdfB+QRRD87+cKV1CtCXUzFIM/0Ijs29rLhDfaYUoY1ZNBzbF26e604QA42oYLtWg8hOaUR+qKcw/osoUF4RVogIlUOxALjTG5pPV4fqkHBKbIlV8MG0jRbnBzMpKKPujMyprJbccsK82u3NeX0ndV8jfL0hfin8JcI326RPPHEztVos4DEx3kcCQ9VHamhu2Q3Cjv9vAzlYCXHwKFTbtCW 5TnMMHrX cv62WWy8iQG82o/yETzozBMGE6vhxIwyWG7PdTyYaND2SDPLwlmnWDlbT/pUtwlM3T5Y0dO9I7ICDDl0ykZ3/1sSMf11iQ66J185u78gjhQGPmVz19xEzOJLBE/jqH8yO1yxJDw93optphiyuqDI5ian4t58WWVSOzllJU/4KVPrPggIH5WDR6kw5z7tTzKsvIh1WxmCb0E+PSwFid/3ySEJ50OrnIYB9pEPU7hVjAB1TAy/I0DF6H0N1StQx7eC5nff+Ie8kNarlfYPPzlqJ2N26fNdFMGPfSww2BlKDxi9n1mxwhtt6sE4WGmRxA6sWhbAZilGVW59uZJ1Y+pS4wLcOKjit6VQwKSNS0ZPeSAB6CA/33PkXhOPsSzskaJRvCTxIdLpiM42MM9x0Vnbyrij7jri1m+AJXV7nHGujux5BiRd3LboLi8niKtgga+ocDuvu X-Bogosity: Ham, tests=bogofilter, spamicity=0.008158, 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, Feb 27, 2024 at 5:45=E2=80=AFPM Michal Hocko wrot= e: > > On Tue 27-02-24 17:39:01, Yafang Shao wrote: > > On Tue, Feb 27, 2024 at 5:05=E2=80=AFPM Michal Hocko = wrote: > > > > > > On Tue 27-02-24 13:48:31, Yafang Shao wrote: > > > > On Mon, Feb 26, 2024 at 10:05=E2=80=AFPM Michal Hocko wrote: > > > [...] > > > > > > To manage disk > > > > > > storage efficiently, we employ an agent that identifies contain= er images > > > > > > eligible for destruction once all instances of that image exit. > > > > > > > > > > > > However, during destruction, dealing with directories containin= g 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 significantl= y > > > > 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. > > > > Reclaiming numerous dentries through force_empty can also lead to > > potential issues, which is why we attempt to shrink the slab gradually > > to mitigate them. However, it's important to note that the underlying > > causes of the issues in force_empty and rmdir are not identical, as > > they involve different locks. > > Please be more specific about those issues. Both of these issues stem from lock contention: - rmdir When executing rmdir, the lock of the inode of the empty directory is held. If this directory contains numerous negative dentries, this lock is held for an extended duration. Consequently, if other processes attempt to acquire this lock, they are blocked. A simple reproducer involves: 1. Generating numerous negative dentries in an empty directory. 2. Running `rmdir ~/test` and `ls ~/` concurrently. This setup demonstrates that ls takes a significant amount of time to complete due to lock contention. - force_empty Force_empty holds the lock of super_block->dentry_list. However, I haven't yet had the opportunity to produce a specific example to illustrate this issue. > > > > > > > To mitigate this > > > > > > issue, we aim to proactively reclaim these dentries using a use= r agent. > > > > > > Extending the memory.reclaim functionality to specifically targ= et slabs > > > > > > aligns with our requirements. > > > > > > > > > > Matthew has already pointed out that this has been proposed sever= al > > > > > times already and rejected. > > > > > > > > With that being said, we haven't come up with any superior solution= s > > > > compared to the proposals mentioned. > > > > > > > > > Dedicated slab shrinking interface is > > > > > especially tricky because you would need a way to tell which shri= nkers > > > > > 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 t= o > > > > users, allowing them to tailor the reclamation process based on the= ir > > > > workload requirements. > > > > > > There are clear problems identified with type specific reclaim and th= ose > > > might easily strike back with future changes. Once we put an interfac= e > > > in place we won't be able remove it and that could lead to problems w= ith > > > future changes in the memory reclaim. > > > > That shouldn't deter us from actively seeking a resolution to an issue > > that has persisted for tens of years. > > Right, I do not believe we would deter anybody from doing that. This is > just not an easy problem to tackle. So either you find solid arguments > that previous conclusions do not hold anymore or you need to look into > options which haven't been discussed so far. I do realize that chasing > previous discussions in email archives is not fun but maybe a good (re)st= art > would be documenting those problems somewhere under Documentation/. > > > As observed, numerous memcg interfaces have been deprecated in recent y= ears. > > yes, for very good reasons --=20 Regards Yafang