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 AEA47C54798 for ; Tue, 27 Feb 2024 11:40:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 22734940033; Tue, 27 Feb 2024 06:40:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D75D940008; Tue, 27 Feb 2024 06:40:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0779E940033; Tue, 27 Feb 2024 06:40:58 -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 EC24A940008 for ; Tue, 27 Feb 2024 06:40:57 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C47FE160B6E for ; Tue, 27 Feb 2024 11:40:57 +0000 (UTC) X-FDA: 81837392154.13.0AF6B5D Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf30.hostedemail.com (Postfix) with ESMTP id 15CCD80013 for ; Tue, 27 Feb 2024 11:40:55 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kHY8QHxd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709034056; 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=3S/Z8jBJq+lr9Qt5zn0chG3N00iUvllaHA3FEjPjzJs=; b=IT1BVFWzgRouS9gxcIkLSwap/rygAQ9uIkMyb5uAAXaiPLcy1r3G8MaqUCX1Q0S676G+mT t+sZf9mAY9jgOirqsWEQZfAK09nsUeb+zmCVmxG6t7KRJtNGxzHRFOuct+mG9kY31iDgx3 O3Ehdw7ZGYFQ/HIbTObC0LSUozLAPsc= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kHY8QHxd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709034056; a=rsa-sha256; cv=none; b=s/1CbZPAwFMVLTKw+5beNMU1efhECnkpgtxb4gd60t1AUniq0b8tIuSiLPYTm/DcjEjClF +wrNDQXWkLQpSZCwGyq6Onlnr8UmdV631WLy5l0CMsGFnyWdvhz/hgRK1wMnig6MO+u8XJ CxQURPeQ2XVNL7Zu9decsgCIuwbn0qI= Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a28a6cef709so637469166b.1 for ; Tue, 27 Feb 2024 03:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709034054; x=1709638854; 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=3S/Z8jBJq+lr9Qt5zn0chG3N00iUvllaHA3FEjPjzJs=; b=kHY8QHxd96vjVxCAGsDXJWW4Xt69f0Xu0iJBrae1ARaMk/qgCNnyqzN5EJ6zCponfB eTaO+euQWEye89KDdKftAzqnRhJ7ATzvwigCdgmZhiVLzboiBUhhpuVyEBAhekoUI4dY qUvQagciYaul/G3H18KQ8MMJcVBaGqo7jw5josMYQMNto2htl4npC7ODtR/geKCgoPz9 lFGrTLof00+l09huNwfAj9cS4uO0QiDKQSBDIWwn7sofcRFhmOl1rCTWeYKu8Bimg0GT zScArrOMbAEhGBbtu1H8rB8EyvfHXHYyI0otaDiStqTLVTfIDKOA2k2CScfhCUHtwFIA VUYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709034054; x=1709638854; 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=3S/Z8jBJq+lr9Qt5zn0chG3N00iUvllaHA3FEjPjzJs=; b=vOUoJjPoT/UX/65VzfKoBf7Qyly9JYjlp0iiYl8CSNx8X4H03g861Ygk2eTzm92ex9 23rW5r+nDH1pgg3tAd/tlK0nUs98HsNIALPRfe6vA3YBc8YNB2XEFN6PB+xpOt5fAoEq T0kSlhHVXJQk2IzFnxABDOHe/y1sp1UO9f8qtnB/T/kKxY24j7i9hDy1H8A29ALh4xIm DfFdUl9GbcHE3GBZRoXR3Nur/JBiNde9l0Z9H/HxC9nRMR6nBVfEnMZjb7/QEMRgkrFS ijqZQaALkgihqdoFgrJndajNLFsZlXUZ/8L9tF5dDMLBgCOKOhJGcn/lCMRH3vzWtYrR qWGw== X-Forwarded-Encrypted: i=1; AJvYcCXZ61IdoO6jphVEbbm8wuA9D8tKoDkpS7ULf+HKae9JTKDhzGb1vtw5UiPf46neLyvnu/8Qu1FT7vuV4BFKwcWcakw= X-Gm-Message-State: AOJu0YyX6giZU7OZo4xrOlkYUxceGrHp4+vMcsGz+1kRE6JOpVi9BQFS /4h9Fx3AFNRZ9mbVpG+JeBpCsDOFp03rizfzYyNjiz1m1R15kykcTcDJGR7bI6H8qTvu37Yc4DB d43x247cTXXFX5XJfvVVZYOm+ZRQQVBiejYWF X-Google-Smtp-Source: AGHT+IEo0rU0Z/Fh2d0SkUQ2s+EG4WCCFpEycImREjVGOWM/A/dqFMrKUF6WS2SuWT3JOumb50PgQN4RgzNjQSUkrc8= X-Received: by 2002:a17:906:6d92:b0:a3f:33b2:5ce2 with SMTP id h18-20020a1709066d9200b00a3f33b25ce2mr6783630ejt.35.1709034054324; Tue, 27 Feb 2024 03:40:54 -0800 (PST) MIME-Version: 1.0 References: <20240225114204.50459-1-laoar.shao@gmail.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 27 Feb 2024 03:40:18 -0800 Message-ID: Subject: Re: [RFC PATCH] mm: Add reclaim type to memory.reclaim To: Yafang Shao 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: 36yo3t3nqn1y1ka7m7g6cktemqi65g3c X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 15CCD80013 X-HE-Tag: 1709034055-291148 X-HE-Meta: U2FsdGVkX19T6Vvz1L1iA522ThkPlnocKhBl+CfKIyleF36lip8nUlIty39N5/MndyzhCvJfzF3e7iCGRo6sl02k/n6rw5TCb6HRNlMi/x3yzN6RNpNFgwngpRWEYElBhG1ejq6i9GcB9aaMzgyE3Mnlvw7kGYY4pLE8WEwhR/tLkAEA2KDLjXizcFRTNADoucyor0LS6sRtwg07zhBZWuAoFtGOLDeAlkNcSGBNu/6x2LPpih7qWOdpUuQVn/M+0dLSHorLJKXPvSdNgD6TDm1tZ7Vi3E+Y3Kr5VOT1WECpJ41qNiM2UwWzISnoMDSzuTdhLVeahVsaJWxY4o7IMsJiE/3p+Y7VcS4nzz1V+EbKzVBG0w7nNs+Do7/1fxTTAq9LHsP0Pjordi18z678hRtF0wveu/of5ZyOkCcHY5qO7PPiIwMPStxTLPiBJKsvUgZFiowoY6fa4ItK8/aag/GmidY7I3yji6aE2Pmh3sb618I9w5oOvgbKfp7iaexYdJ9KPUpi7AJkzXWGpOnxOlVxDYnWWmzqQQpQTZ2DiDKNsu33h0GuykshIBC6UwRUifTWlUX9SOEb+xDVEUfC3GNNaz3HN+FmYSoS4nQ3iUvE3AyH+5xsjM5DbdFEq8fvQ8ZoCa86zJbvMTQ3KWKXMRvePNkwyN/7o/mbwVuKXGkpo+i4lsqYbaiKAPlNlXe76HREEu7IWELb5xJUmk6cAAX2R/S+eKG9YoCpqEMTmC9n7Mcd0GkWO/SRvDQwm9A1S7BVbyCzTPKMN0wvbXXeK7n2Q5kcEuEt+mm0iCU6opoa5cG/q/AltoqB5y67SNBHaFmdv0oxQTnEhAmsgy9wroA6vFMSkr7hYnxYjOn/MuK6mYY28XdykY3VN/IhvqFszCpIZBgtv47wm3YT9GAIc1EVeX1oL+q5+bhQqxrvWv2cpn4Z60/GvZiAT/8zJC5KkID/zTJ/GRX1aOQ5T/Y yFY+cMHP ltwV+NBMjb/HGnj7h16bZElZ7bX8EqoOzdnyZJUFITiImzXYCxcX4DCM0ZszUq9StP3W+ X-Bogosity: Ham, tests=bogofilter, spamicity=0.018974, 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 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 conta= iner images > > > > > > > eligible for destruction once all instances of that image exi= t. > > > > > > > > > > > > > > However, during destruction, dealing with directories contain= ing numerous > > > > > > > negative dentries can significantly impact performance. > > > > > > > > > > > > Performance of what. I have to say I am kind of lost here. We a= re > > > > > > talking about memory or a disk storage? > > > > > > > > > > Removing an empty directory with numerous dentries can significan= tly > > > > > prolong the process of freeing associated dentries, leading to hi= gh > > > > > system CPU usage that adversely affects overall system performanc= e. > > > > > > > > Is there anything that prevents you from reclaiming the memcg you a= re > > > > 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 graduall= y > > > 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 u= ser agent. > > > > > > > Extending the memory.reclaim functionality to specifically ta= rget slabs > > > > > > > aligns with our requirements. > > > > > > > > > > > > Matthew has already pointed out that this has been proposed sev= eral > > > > > > times already and rejected. > > > > > > > > > > With that being said, we haven't come up with any superior soluti= ons > > > > > compared to the proposals mentioned. > > > > > > > > > > > Dedicated slab shrinking interface is > > > > > > especially tricky because you would need a way to tell which sh= rinkers > > > > > > 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 wro= ng > > > > > direction. Perhaps we could consider providing a kernel interface= to > > > > > users, allowing them to tailor the reclamation process based on t= heir > > > > > workload requirements. > > > > > > > > There are clear problems identified with type specific reclaim and = those > > > > might easily strike back with future changes. Once we put an interf= ace > > > > 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 issu= e > > > 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 type=3D > > argument together with that is a recipe for eternal confusion. *If* 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 serve > as a foundation for potential future extensions, allowing us to shrink > 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, memory.reclaim and memory.shrink would still have overlapping functionalities.