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 8218BC5478C for ; Tue, 27 Feb 2024 12:13:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 19C8F6B01FF; Tue, 27 Feb 2024 07:13:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 14D266B0200; Tue, 27 Feb 2024 07:13:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F30126B0201; Tue, 27 Feb 2024 07:13:06 -0500 (EST) 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 DFEFB6B01FF for ; Tue, 27 Feb 2024 07:13:06 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 86F881C0CA3 for ; Tue, 27 Feb 2024 12:13:06 +0000 (UTC) X-FDA: 81837473172.30.D60EB38 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by imf04.hostedemail.com (Postfix) with ESMTP id 01F554001E for ; Tue, 27 Feb 2024 12:13:04 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mvWSNNii; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.43 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=1709035985; 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=44AXWI8G6ESfPz+VY9q72sNFsdIEcSMvOKIy0pHRsKs=; b=MY9LuRLDtaBXZxfGoqXSLaJ5MQNPe34a+YLU7eDt1GXAG851rIJ4UOCFFiwVzrmrz+bu9v mE+DQYdKQIucriliPBQPgngbEqcfS43e/egPa9oFMFu6UMiF7pHQmdU2+ZQV5p9FlsVbcL a9Ook5tpgFzvs6D5N/FwVLUgYozrfjI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mvWSNNii; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.43 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709035985; a=rsa-sha256; cv=none; b=v3HlxfHn3ApWp9yyr9tUk1VZekPPP3+LuwqR+YhaitJJmN6n7nM7vsx7SdW6unmSKrQO5D zRa6J7HI18mCKe5miVtFo9ejt+K4xmYGQ95A6ybTvkhUjAzXGNRXib5s4PlYfiTnbQuDgO zjPa+M0HreCEoQR+ZS9q30ZIT4RlykM= Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-68f4bad3cb3so13364516d6.1 for ; Tue, 27 Feb 2024 04:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709035984; x=1709640784; 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=44AXWI8G6ESfPz+VY9q72sNFsdIEcSMvOKIy0pHRsKs=; b=mvWSNNiiN/HVJQLloKh3aOOVz1ucjkGeDGYaduWkFsLIBk2rRWhK+pnLu3CXn4d+Zf TUnL/+ThwHJsnPX7I7bmz4vs38mzHvco4q2drJLomQB5fz/3tbFJNwbXqCZ47H+0FLm+ DO3PH+KU6ttvHiI/TpAdf0Dfn5IBvZrqAvqQzKPv5SuQFXZ3FOLVtxlGA44ExLREy85o K5now0Xj8aANG+2XlnNWu7sDIrzomkkUy97ZDNudtnrX3TEsUjduG1w/pMt9BBtKIHoA MKyjRf616i8In36pdCR5syhA+90oJLcWRRmngT2WmksVec2iJiyo8VkyZncJycHVHlnL TQhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709035984; x=1709640784; 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=44AXWI8G6ESfPz+VY9q72sNFsdIEcSMvOKIy0pHRsKs=; b=hIAq92Bh7RnFzsqLl/MdiTM9HEwmAnz57huQG1Vt2Y89n4Nw8vvKOGNzMdc2OxLpOk uKSALU38OP9OUEww9e0CdjvQ9pvXxJTAA8Wvl01+CZmNyXf60e632W8vBV6augZjHekS fHP7P2eAWOkUpMNirPbTn8Ymn/rpD3eeLSrIIosGnHRZvufXpO7960yYhkiVSSK5zCEx WXDtYvwej+iNU1zt8KJeg1Iwaoro8lN+ssfvJMoUHeYrbktZlTTKYeC9fz9PkI++ABaG AEfr0oL27AhWjItjcGSX/tAYqjFcym4ZeHoerJLrrSDFSmgBrtnn6dzMWlIfO5GlYsix 5Mag== X-Forwarded-Encrypted: i=1; AJvYcCVzZ7Rl2s2EnPWnFMp2QTV1gUVwk+77ts78UJqCNMlA3wwMtciEEi4Sn0LuBdOfA/bE8DA1kH3xQ90jvHgfl6oAXRo= X-Gm-Message-State: AOJu0YywDPsneEX5EUEnw47CtqVZs4ygNBA3MbEyyg3Hp2blyNtUEh2U 9pJJ39yRcaqjzFohZlNIzt5qDFw3iIbKMEQ7PWHtDK6Xj6JdRE3vh7SQKUHhqUSGriDBG5XrY3/ cWCY1h5+gSkPORh5oOobizOJbjHTW5vM6PmSEMqFI X-Google-Smtp-Source: AGHT+IG3zCZm8mNuQyt1oBMrXb0jLhsuQvkIwynMPcuHuQOduT/wOzfFgGro7iqqpW6xu600h1wnvogN7QlYDV16o+U= X-Received: by 2002:a0c:e14e:0:b0:68f:e35b:4c51 with SMTP id c14-20020a0ce14e000000b0068fe35b4c51mr1723307qvl.14.1709035984035; Tue, 27 Feb 2024 04:13:04 -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 20:12:27 +0800 Message-ID: Subject: Re: [RFC PATCH] mm: Add reclaim type to memory.reclaim To: Yosry Ahmed Cc: Michal Hocko , 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-Stat-Signature: 6yhm64ppjwu8i5gngmeeyq54nesbwfbf X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 01F554001E X-HE-Tag: 1709035984-810044 X-HE-Meta: U2FsdGVkX1+kSifRB2Il0KqQgplySPZbGF9jo7tRm0cO7CnEVOG4vekJu+uzwxEo4cQZGNPSzHp4Hpy9FWgDtmzKCAVg5+3M/WI867OfRLUF0A4KXj+cWP2vCgchSYSsLcVC1hiBC1s2qS5KFViGV02lV9wnZXDywEu816aRRFUcR/3XhSpjwR97K+1VHyZcn/08CsV3V7kMHfM38JSAvvEMFQ40Si+N8Mzs1UcONK3O1CPKZ36ePVcgZrGCKApzFHpoz23mC1IRJqAcKlZ1n9NF0X+s1WEfZgwOmRQaVXzEZzN2s0H24gc4doilt2w0xIfbshmrXU6x/rfEATSzCbMImj1PGPANiESjeTOwpx2nHiUie0lT5JxkAUwIzwPcBJmgS7zmB7RE4o9tyOMt5OvETFNTfetOjN4pGQSYZ7DEZLY5QM01tePgzHen4IQmPNb5PIWDNnwwZYpYuiFdPl4W2m0FVXDDkzboDc+94vhumn/Ze5AO/CnNgkhWc/XpOPdU42vATe6uRjyJiMHBwwJto2ZjDx0kk9R5SYwN9Zq5cWeKCi9yRqW8un9V6RDSqeXFvIIJHyFnGB+Fm2m0OITUtCv9+EFw3YPrEt67K6lNgOe/VgQ4zHQEHrgfx6hsP4OMJL/djGNL9wscGsI64fP4m/LUELhgftWeM9U0SjkugRbql4A6IYlpG/ggfxwGLn8gRL09o9HFX47abIYgjirYpan8isBE+OosT7QQp2izM7LoVLpM6M7hrkPPzBiJf6trawEuVwVRE05kNlIuhwwi0EBVhdQxbyqQWiSJzAvkn6U2HUbk+pBZLTCcfif40gB4j7hzX2tdI9i0LN1s0hZxjVg8w02s1D4ahXGvSUvm2HUDMoVr5lUz+gOLLEWMhZ1bxGeVVZ964eF9f7NOFakMAKE8e0A2wY09Y6P/x3SH+JROH4F9NvdACLGlU3HSND8PRqJcFtIvf6YEagI +nZXE/mQ pD3wLrb4dFllLw2n8CMqtbU3z2j1YdYcn7Epjt/hgF27r+A9Qmm3yi2ypWLNIx88ozZfQ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000750, 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 8:09=E2=80=AFPM Yafang Shao = wrote: > > On Tue, Feb 27, 2024 at 7:58=E2=80=AFPM Yafang Shao wrote: > > > > On Tue, Feb 27, 2024 at 7:40=E2=80=AFPM Yosry Ahmed wrote: > > > > > > On Tue, Feb 27, 2024 at 3:37=E2=80=AFAM Yafang Shao wrote: > > > > > > > > On Tue, Feb 27, 2024 at 5:44=E2=80=AFPM Yosry Ahmed wrote: > > > > > > > > > > On Tue, Feb 27, 2024 at 1:39=E2=80=AFAM 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= container images > > > > > > > > > > eligible for destruction once all instances of that ima= ge exit. > > > > > > > > > > > > > > > > > > > > However, during destruction, dealing with directories c= ontaining 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 sign= ificantly > > > > > > > > prolong the process of freeing associated dentries, leading= to high > > > > > > > > system CPU usage that adversely affects overall system perf= ormance. > > > > > > > > > > > > > > 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 gr= adually > > > > > > to mitigate them. However, it's important to note that the unde= rlying > > > > > > 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 usi= ng a user agent. > > > > > > > > > > Extending the memory.reclaim functionality to specifica= lly target slabs > > > > > > > > > > aligns with our requirements. > > > > > > > > > > > > > > > > > > Matthew has already pointed out that this has been propos= ed 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 wh= ich shrinkers > > > > > > > > > to invoke and that would be very kernel version specific. > > > > > > > > > > > > > > > > The persistence of this issue over several years without an= y > > > > > > > > discernible progress suggests that we might be heading in t= he wrong > > > > > > > > direction. Perhaps we could consider providing a kernel int= erface to > > > > > > > > users, allowing them to tailor the reclamation process base= d on their > > > > > > > > workload requirements. > > > > > > > > > > > > > > There are clear problems identified with type specific reclai= m 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 pr= oblems with > > > > > > > future changes in the memory reclaim. > > > > > > > > > > > > That shouldn't deter us from actively seeking a resolution to a= n issue > > > > > > that has persisted for tens of years. > > > > > > As observed, numerous memcg interfaces have been deprecated in = recent years. > > > > > > > > > > There has been recent work to add a swapiness=3D argument to > > > > > memory.reclaim to balance between anon and file pages. Adding a t= ype=3D > > > > > argument together with that is a recipe for eternal confusion. *I= f* we > > > > > want to support this, we need to have a way to combine these two = into > > > > > something more user-friendly. > > > > > > > > What if we introduce a new file, like memory.shrink? This could ser= ve > > > > as a foundation for potential future extensions, allowing us to shr= ink > > > > specific slabs with specific counts. > > > > > > Shrinking specific slabs is something that shouldn't be exposed as an > > > interface, as this is a kernel implementation detail. Also, > > > > If that's the case, why was slabs info initially exposed through > > /proc/slabinfo? Isn't that level of detail considered a kernel > > implementation detail? Currently, users can identify which slab is > > consuming the most memory but lack the ability to take action based on > > that information. This suggests a flaw in the kernel implementation. > > BTW, we even expose more detailed kernel implementation details > through /sys/kernel/slab. > That is really confusing... There is even a /sys/kernel/slab/dentry/shrink .... oh please... --=20 Regards Yafang