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 25A8EC5478C for ; Tue, 27 Feb 2024 09:39:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A053294002A; Tue, 27 Feb 2024 04:39:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A4E0940008; Tue, 27 Feb 2024 04:39:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68E5E94002A; Tue, 27 Feb 2024 04:39:40 -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 3C24C940008 for ; Tue, 27 Feb 2024 04:39:40 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 14E79C0BBF for ; Tue, 27 Feb 2024 09:39:40 +0000 (UTC) X-FDA: 81837086520.02.735450E Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf01.hostedemail.com (Postfix) with ESMTP id 766B140014 for ; Tue, 27 Feb 2024 09:39:38 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WC6gSLst; spf=pass (imf01.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709026778; 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=z/5se73RJAWQVT29uKHnj1P1bgKyxQb1ZwkPnywT8+E=; b=IVb2RfGnvzcLnitVmXP/YszUwj9KYhvyGvTturaPCOGLB7K67YnWQ8ezXf1QL0Z9QliTMY vNRnTcQeiiea7ptK3MpsPnuC2tpEnUy+EvTtyxe+DQo+tbfdchsJ+ri+zL5UJpQTyWZ4kC UME5E4UyStxuXyiW7581OYWdAFj/NkQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709026778; a=rsa-sha256; cv=none; b=z++jusEh0LjOHBl6zsukA6mKceUTBNP82034JRQeUTy7zPX9f88MCy5k4WHRaqn1rZx4FT ry31Xb+uQ1aXVYFTpZsakzR0Finf/8FGdecs2m5gFW9EchdesYQS/98FegOSD+1RfMoBD/ DDuFihfRYQ6RW+uVZTDwrPffOee9NUo= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WC6gSLst; spf=pass (imf01.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-42a9c21f9ecso15549441cf.0 for ; Tue, 27 Feb 2024 01:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709026777; x=1709631577; 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=z/5se73RJAWQVT29uKHnj1P1bgKyxQb1ZwkPnywT8+E=; b=WC6gSLst+vMvRnLP4KuvRIYxM2TY9GoaJLqsy8IzjSyoSxXw/gRg4peSWgJFAnfhT+ 3rwiuzLeO/vwyzrY39XepTWY0CwCWLmfEBUZXhl+JhEIZr6M6D8o5uz0nxX+od1sTCeF 8V3HDY3NyK4K454GUb1ZIUHTM386MytO1t4U9t0dZoqiQ9hJs/AntgIqh3ka2etMJoVU yTIc3Au6E9qSz1FOI3ZkX8tXnI0GG5z1mXwFSGA9qiLp0IAD0/uhiXjNHIWPocN2O7bB e1FaYuEfS+uuI9F7c13FMe7kpZNN++KYZQgMuYyjlnLabcq7H3zpoV7lneVc/KkMNnBM kyng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709026777; x=1709631577; 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=z/5se73RJAWQVT29uKHnj1P1bgKyxQb1ZwkPnywT8+E=; b=sP+8ynnzKnh26GzTkusQnLE3+JyjQz/dqdDmDAu1Y7nCtDNCskj5gNUXhqYKjoii0A B/Vqtqkrues9Lcb/hHV6WJnxXUAKcvz9GsvsZs6iYrvL2I348GyioxOeIgXPNQC0HZ2l vohvkpwldbEeN8BzpXR6JCC+ofyKywiY/MGOT6kFCiwNZZ+O8JRHtYmqi/m4/R8K/miF JWRvw1jPz9IMGlZ2X9/OoXpH6ZSRGSYEeVv/7VT4lhJtGHWvCG4mH/EJd3hg6MnkRed+ kOiyZ78ifxPquOBKFVc6shT3u9gVUr7gkFyhtn20R/9Ri2fsEEGQmo9KTdzkPP0nR+Pq CBGA== X-Forwarded-Encrypted: i=1; AJvYcCWBwZPdSWvK9muyt6+9eoJFqrAnYrIch1s1B1p5BBiMN0qva5zAhWdj4gQYhWglx2EdMJdXvSDr9hhl0TOhY7CUFPc= X-Gm-Message-State: AOJu0Yw/uxK1uzFgZPZga1D322RR4HJT98yFK4PaGf/Xj2GKU3fkTWkl 5Ph0e0WoGNbUS3RetNc3v4LdztinM7/oV7gAuWf35ozzEHYU+AiG6uxG52cRdsvxqwiABdaJRtX rqP/pv2A4sS77TFtztYiqWEisaSY= X-Google-Smtp-Source: AGHT+IGLC4RBNzcxJYrWcijQyR67JvR2p7GLZIGNPfR/PR6/oFU40+ZS06vEfSp9JZPkq03uJmMQMRDr2WI0BDSUwZc= X-Received: by 2002:a05:622a:149:b0:42e:80e5:3c with SMTP id v9-20020a05622a014900b0042e80e5003cmr7012691qtw.6.1709026777487; Tue, 27 Feb 2024 01:39:37 -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 17:39:01 +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-Rspamd-Queue-Id: 766B140014 X-Rspam-User: X-Stat-Signature: jibariudmkpgd4j66ndhiy41n34do7j1 X-Rspamd-Server: rspam03 X-HE-Tag: 1709026778-136774 X-HE-Meta: U2FsdGVkX1/uNQ8hEXPUD5qRVV7eLUfb3Ye7nlR78TG7Ytr5gi6tlBk+TMMUmlP2YvitskcQSzroLtcpaT8iI2ec6V+RBU1a2deNRv/gkixN4fA6190oTsA7WjfBvTW105geo3rkAhIxuRMKaA6akZFjB5LM6FZYBYe3N59IAxSpGJLW49lW0CTd0tXN4k6bZMZVdCSRwuvJDzRut+AnO5mTginSvutiTkMz/sv1sFVfxbDxmhkJ6vC0Xu3qRkD4fSLC+sPl9JLDwAaQdzBVg5c7M71ue2GhWL8HX0GGiFPilpLxFfd1hhKi7U4CV2/tSR8Es9qcbRWyCvFqqJJnwTZkKnNigd4PW5xiiqI2iqaBSz6TUu4Fj0gSlwzL4HiwNwDmehToDgLa3y1MN+3CKga8ApiZ5q+q+Fc8/tQ3hhEzZWcFxOWvEWiUp79TkgX2TOF6MT3WEma13z2YmRp2/qRas0W58Y4N8m8ljKP2I06nqdkd7RWCoUbKct2ixdK/MZGUYlSBzo7HUhGEO6Fi55R58CvA5OAC9hU8rytfYDUKSUvo98Cj8JU7D4beZmTzsiDfn9FxBf1UjBWcDfhETOdSf9UbQCGvFye1bRGT4DSAirEYeCjs5WMT3fo56p6OnnPcjjRt1qciGEmbtPBd0vGFkRv3itolrsdczxCthVLVOoeTUrRnH9jc/Gv4gvVloaIfyxR4wUhLyT9rn5OV2j2JIzW0neYMmADea0dEcjBGr17Jc6QDV53Tsp3pGzYua3RY4b7F/rE0pXgFPdRVgSXOOFJXHYlFrCRW0tiUFc+X7eaqH/xWyPTk08bueQPKU4KRbhssSi/FEx+36tS74i7pzSnmlsr+YC7XtTZzjyOwiJK9tjAr6rVUGWYn0xt6Ir3NvdlrF5DOJ5D/ArpcJNDHpWbY77ReoEnJ7mVhdj1BSI52rav3/HD7yH7j0exbusy8vTuPonvd7XZp/8Y SrRy6KpR Ke9xugbCxTtZZbIrsDqcWeDZkSqeUqyePCqBGFE9CsgtnKQl9d7jN26l407o5xGxiyZ/E X-Bogosity: Ham, tests=bogofilter, spamicity=0.078868, 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:05=E2=80=AFPM Michal Hocko wrot= e: > > 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 container i= mages > > > > eligible for destruction once all instances of that image exit. > > > > > > > > However, during destruction, dealing with directories containing nu= merous > > > > 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. 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. > > > > > To mitigate this > > > > issue, we aim to proactively reclaim these dentries using a user ag= ent. > > > > Extending the memory.reclaim functionality to specifically target s= labs > > > > 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 shrinker= s > > > 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. That shouldn't deter us from actively seeking a resolution to an issue that has persisted for tens of years. As observed, numerous memcg interfaces have been deprecated in recent years= . --=20 Regards Yafang