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 3EE8AC54E4A for ; Tue, 27 Feb 2024 14:52:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B4CC280018; Tue, 27 Feb 2024 09:52:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 96300280017; Tue, 27 Feb 2024 09:52:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71E38280018; Tue, 27 Feb 2024 09:52:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5D9F0280017 for ; Tue, 27 Feb 2024 09:52:28 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F41AD80BDB for ; Tue, 27 Feb 2024 14:52:27 +0000 (UTC) X-FDA: 81837874776.07.563351F Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf22.hostedemail.com (Postfix) with ESMTP id 61797C0017 for ; Tue, 27 Feb 2024 14:52:26 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P33mPxMO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.46 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709045546; a=rsa-sha256; cv=none; b=xcClIckxR1ifLJW3pmHVaRKqIu22mnNuqIH9hgTOYZmgLpTQyBS0FFKZoMb75UhRnM5jjM iiZhoh5GDo1qDToKuJCVZgqDgzk6Py9Si+8gidZR0iWS+2qXfYOxgnLcWEdWozktG8ZZ8z APgkLmkjWlPAj4Omv4hRldgbsnLeK0s= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P33mPxMO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.46 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=1709045546; 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=drRKPyhyir9gM5A5phgD8aRcA4+U24mGTn6jONfVc7U=; b=wAYKUug4F6dYZGe8/h35G6j8Xj9O78CWY7v4gB01neTQzMeXoIg99XWiuk5PLpG93aSl61 vO5NTQ47eRTdDzJ4hCaIAqKaAaGbxM5bEob+2Pwee6rvGbWodKdc0lUnVH2qqRIqWtEreh qwD0BOy23cTikYr1VxvUE3moxcNUd2o= Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-68fef04c5c1so10841766d6.0 for ; Tue, 27 Feb 2024 06:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709045545; x=1709650345; 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=drRKPyhyir9gM5A5phgD8aRcA4+U24mGTn6jONfVc7U=; b=P33mPxMOXcyxtc0ILJYtRQaVCU1HtRbAJtYw6mMWDtMtsqJzngef/EqDhLIHWezGYE hquTMJ3qvfebad2+0z8mVGLt+wVFBYy6oRBt9oXwQDYWwhmn15uzj8fHYpW1uobi9Rzo 4NPjjO3iHfBcVFBlCXki22Z59kuanLR5LR4Vyx10W04ImNlzbS8EM0+9p74oVHiQN4B/ focHwCMUTAZwQkXnPjNZ5YNPUVLk2RdSVdvGmtHHg5gGc7izjmdeparVrtie0DIaqjEF s51jKb5hwbd1f1qWSdTkakPaftCo/ii3PeCaaAZ2GMtI4h9ifeylVhviMgik0s7l5eGK ANZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709045545; x=1709650345; 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=drRKPyhyir9gM5A5phgD8aRcA4+U24mGTn6jONfVc7U=; b=iwd2x4OQobSGBd+M9iNBici2SETAn2SOcytoSeVfkcYfIPCDoQyjy+dU3cMGGchdOk wUHtxjm+obPCShS2pVJaGCBsmpY3dBtGEqQHymCIcodsj/jy/xV6PpG3W1/3qR3INB+5 EVgfEoYdrZ09j4d7dx4VS0IIHPK8PrbAE+3j0D3nPtWYLUzEPWWWfGKOni5uQGcngbVm Qm9CHinAlKewjUeRv/EQ+bQDCrKIGjC5AzF6q7m1mVwzlLwpYcs5J77lTokgO4tXrB2n jgASGiuqxTooR/0zWLrS7ML/6UOXNhBPe9xHbuZ6j/HtJzRC7imovR6bzAhWvd/+eMWB SCJg== X-Forwarded-Encrypted: i=1; AJvYcCV6yBLIEJUEXc98TU5EdaEmx+TQ7vhNHrGHsMx2VMzFUQahSH1PbpZtiIYlm1396HKWqNW6lLiMaChKJsZTWftsJU8= X-Gm-Message-State: AOJu0YzXrc7vJ+4OBTcxBbsejhk8oSFXr2pQz6yEj6yIrxQSHuaLAOw2 I0HDB7nHvple36tYSBaIyEntRZZVE2WVaBx/m/0g5WfkDpcMW0vMh3WdCJdpjdbDqcO7DWe4cwz n9fbE4nhDzR1dr0z9aOGdEth1yYbEE+PPGqKWdlPd+Hg= X-Google-Smtp-Source: AGHT+IFfhBAzzDBL+eLWQG3FrfUAFuYW/P8qLgyT0DIm9lgaJpVegttogh8uJjLNVsYjXW2z2tu1J7ssCUOV9QBAwYc= X-Received: by 2002:a0c:dd8a:0:b0:68f:e84d:9203 with SMTP id v10-20020a0cdd8a000000b0068fe84d9203mr2132857qvk.2.1709045545492; Tue, 27 Feb 2024 06:52:25 -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 22:51:48 +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: 61797C0017 X-Stat-Signature: tappoiiu6u74bn5tb63ayfnsbhcs9bbm X-HE-Tag: 1709045546-735786 X-HE-Meta: U2FsdGVkX19XuhMHswSFeopT858xdKIm0lGMuN64LrZgUM5at6LAvBwJoZuUBulU2PGNo/hV0lYq99h81KM0hNRb9IBcVf2f0z+w74jSx5rLphAK5fFpgMufcFkvKx8wZqbaJ0Yelv92RA5GWIig9Q6+3lzfYfugpVb7pUKLtn7dSJsNWql8+pG5SVlN2UlYdvpBeAzYapH4DuQoJAy3RXUpAKI9VKTat2HmlpM+isQQowPiQ3FPmoLvK9udkVq5jjH8d92EVTwHfGjQCapnuJWcOZHkNfNfVDQxl+SpRsJktFP8Vnt0N/dJPwQX3xu/wXLnQHlZa38c4LnTZtHeAyZM6ghrL+MhhmPi2wOThAPw9Fkc4mlW0LyL0aegQk2V/Dy3JYKqpc7BC6opNqMJlG+Rz0Fslwbm6s28LDi1oOTMCXwr3HhA9eCH460EZnJiCuVh+V58KuMPpj3MdxlFbOdNOBaTwVjGol+GeyxhaIfrd75wybUyPV43xSaoaCvlGxGToJJ6EQLBD/jnkENdSXrUq9BXPA1IjL5P//lENKX9Gd682HWWIse5pNP13b53+sosUO1mW0Y+EsL4lwBNtvD9YYRowxrlO2artvdoxzKDnoplBdP+hrUNhpFVL64gx2phowFfqYnqZcaQiiN4a+/UMWLf9Smeube8QjvHh+/Sic6w510rIHyhxhlGlH6F8E69rYU7WCIrYFYWVmEPToHNOwQ4Zcaxa46xsCT1xuDBOj6f4XIcDjyvZtGmTsCh/nTvUggCm6x3YruyQv04kgBwcprW7S4t2bDN6zKeLtGudyzGxC9FGJvxU/B4/SoWh5HgxEKsZcwaF+1JT9IDa4URpEiD3/Ci5SRBL7yMDf/pRlIO9jtFSaSF256fbIJxL2vYz434Rjmd05fxAiATpRepgaKh9r/V2sG/XZhkf3FaIgtLycYTrDQCHs5ZMIiHdtbBz84yLyFgbt2TGnO 0HmCawMB 8btKb8BIh1VfPIbGGNe0kBBc1ac+LdHWh5Ac4Kav+78tverc/zFaIyeXSkgZB25gtmDc+ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000052, 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 10:03=E2=80=AFPM Yafang Shao = wrote: > > On Tue, Feb 27, 2024 at 9:20=E2=80=AFPM Michal Hocko wr= ote: > > > > On Tue 27-02-24 18:06:05, Yafang Shao wrote: > > > On Tue, Feb 27, 2024 at 5:45=E2=80=AFPM Michal Hocko wrote: > > [...] > > > > > Reclaiming numerous dentries through force_empty can also lead to > > > > > potential issues, which is why we attempt to shrink the slab grad= ually > > > > > to mitigate them. However, it's important to note that the underl= ying > > > > > 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 loc= k > > > 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. > > > > I fail to see how is this relevant to memcg reclaim > > > It appears there might still be some misunderstanding regarding the > issue at hand. > > The numerous negative dentries are generated within a memcg. I > simplified the explanation by omitting the memcg context. > > > > > > 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. > > > > OK, get back to us once you can identify an actual problem. We might be > > Pls. take a look at the force_empty->prune_dcache_sb->shrink_dentry_list. Please note that the spinlock is located within list_lru_walk_one. Additionally, the issue persists even with the newly introduced memory.reclaim, as it functions similarly to force_empty. > > > talking about different things here though. My question is directed at > > existing memcg interfaces to reclaim the memory. That would be legacy > > (and effectively deprecated) force_empty and memory.reclaim that we > > have. > > > > -- > Regards > Yafang --=20 Regards Yafang