From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A94083CDBAA for ; Tue, 28 Jul 2026 07:18:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785223107; cv=none; b=TJRWhP/TkLAiVezjoc1ixCmD9Juox+eBAYfOZ6Uzg61oGt0edT7MTLG1YwMmeVskxpIdRsp7PHi3/W5YBDeQyp7jVfPh3YbWgREHfHQaKG3WcneUqiv4Y1Tj8fmttSXLBujroa+jBYOIHXhjhD1zUp3gLEPaSrynTF+oNDoZr2E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785223107; c=relaxed/simple; bh=8ByZUNH3pZK2lqGrVo0J2cEUmTcQMhBcyRLalsOrWT8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=t5w31+8PbHDtgZHpCzbPNlE8jrBwoOQUCChZfKl/lU0GM4+VvAeUtfIRPt861zuzdh/mrMpgIryAudbR4E7L2sVmnc7dfbcy3FpEdRurSlCDzBtLbyytUDQBb7Yno9cAmPshoO2vLMOd2Pw7kG5k4gb67FzJrcPz60XYb52I0ww= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Y6bZabnP; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Y6bZabnP" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49550ec592cso3838455e9.0 for ; Tue, 28 Jul 2026 00:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1785223104; x=1785827904; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=zmmSvrlxWx0zbydU4JmOLEEoNStv6+OLm9+6rxzaV9g=; b=Y6bZabnPyNRWnsTBHthmcJnXq+YYjfYV8A5YypAvmrH5KWxs+FN0bcKrRJh9VWPkfb w7tPF8HbLEoPoyuMPWqmk9OYjk2iXZEPY298heOKbugdejAJPm1Rt5IcTd3wkcxNMkEX cMbp6fs0xUv5OXFIVh16qQRRb8fBNxyNi8jhOYvGZi+GAkQMqMsNb6XbYL2cleqi2MZ8 hFcWkhtapAmDHH3sZHn8BvsH90bo81mjU8cdVeXl0GkhZYGPuWgboVhwQ+FenTrpBOa6 SNBjhiJ1gGJbZkRCRrZR1C3yXZM/A61tMf7bXhWs00EEtYl44xjzjn/qEy1VtfZnNrg5 Bl/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785223104; x=1785827904; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=zmmSvrlxWx0zbydU4JmOLEEoNStv6+OLm9+6rxzaV9g=; b=eDSS/zeMu/PsMlHfInANrtZZrl3FS+ipvC/tC0GZFiLwSnuME6yp+RpVWZLbyj6IQO lj3mKqyjreZ6GlmOz30Ju0sptwJqI6gIPddFup0AW8DhglMEBYLiTtbBWFI50JThARgu BjgrhjwrADXogi3q+zel8DRQlBljyfbu/u3Hde5KLfk4yLU5JSfQPJMSzaR6cXsZx3SY goGu9O4a267csPcqWQnThGeWDikXJ43JcY++KdDXnnLco8jhIBpGXSLPByJHGzmAYJk3 GsypDcNNGjSwfayIEcafYHWxcW3YfPm/UkRFb6GT/IgyOeAyurwGLUP9lz3eAKH2Qotx vJJA== X-Forwarded-Encrypted: i=1; AHgh+RpvwWfLC8hIZt06Dq/YVwg5GtEG3s8Ngs83ZL6R5qYQAoOU6sm9+CmQ7sk8Uo0dYSgMBkSPMW7GvOul//U=@vger.kernel.org X-Gm-Message-State: AOJu0YygH6YnVuQD/UfljSEt/zBzHDztFenWE1dCui30PZyH+0/rAQJY wocotl4QvVnw5KQFZNWC6jlA+n26mjHoYaPr8Dr3A15+VPxyt3G2z5AMRarFW5wqVwk= X-Gm-Gg: AR+sD11vW80SHrm9FK8RzS2a00jtPgr8eKSwMXYCJhZGmRVnZppU85/GYGYPjUthIpx XcYUyq4Db4uW4+cy/yqbpFFEauA3IZhiJegUFBkxfGhFPukgXnmCdwmcDBn2ttLxCvDIQ+fOBxI O7qr7fBK7i4EC4oALTGFRV0kNWK+btuSkoZX8KUmZO8DBvRmMKGlBeaFB53AWZhiqxE1vXY8t6k KwMqv8oydYyOc+kTAQh2VBM48cteiSBbLgp9GUmDNpNz5rs9EIqw+tsOyrn8euOnOhlV6gGbavv 2ixPoE5WU+y+0Mz1N/Mn4gNKe+xGhwVWreBwKRxt7ZAAvxWzRurnVpyW1le9yeWLrfCIDZ72DG9 UAdVwOV4NbLx5Mhl2eNKu7dDWBjcsKUTDFsZ7Door/Vhd/SdK2Ljetbtb1Z3IUHqnB+DhwPMAKn PBPB+25/zYv2Sb6NePKm4+ X-Received: by 2002:a05:600c:5291:b0:495:6193:c6c0 with SMTP id 5b1f17b1804b1-496c658f6cdmr10777075e9.18.1785223103682; Tue, 28 Jul 2026 00:18:23 -0700 (PDT) Received: from localhost (109-81-83-7.rct.o2.cz. [109.81.83.7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4957bfd1a60sm284262325e9.2.2026.07.28.00.18.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 00:18:23 -0700 (PDT) Date: Tue, 28 Jul 2026 09:18:20 +0200 From: Michal Hocko To: Barry Song Cc: Ridong , Andrew Morton , Johannes Weiner , David Hildenbrand , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Zhongkun He , Muchun Song , Davidlohr Bueso , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ridong Chen Subject: Re: [PATCH -v4 1/4] mm/vmscan: fix anon-only reclaim evicting file pages when swappiness=max Message-ID: References: <20260724033435.2573323-1-ridong.chen@linux.dev> <20260724033435.2573323-2-ridong.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue 28-07-26 06:35:20, Barry Song wrote: > On Mon, Jul 27, 2026 at 7:37 PM Michal Hocko wrote: > > > > On Fri 24-07-26 11:34:32, Ridong wrote: > > > From: Ridong Chen > > > > > > As Qi mentioned [1], when swappiness=max (SWAPPINESS_ANON_ONLY) is set, > > > the reclaim logic is expected to reclaim anonymous pages exclusively. > > > However, due to the current ordering of checks in get_scan_count(), > > > file pages may still be evicted if can_reclaim_anon_pages() returns > > > false, which contradicts the semantics of SWAPPINESS_ANON_ONLY. > > > > > > Reproducer in a cgroup holding 64M of file cache, with no swap configured: > > > > > > Before (file cache is wrongly evicted): > > > # cat memory.stat > > > anon 196608 > > > file 67178496 > > > pgscan_proactive 0 > > > # echo "64M swappiness=max" > memory.reclaim > > > # cat memory.stat > > > anon 208896 > > > file 4096 <- page cache evicted > > > pgsteal_proactive 16400 > > > pgscan_proactive 16400 > > > > > > After (file cache is left intact): > > > # cat memory.stat > > > anon 200704 > > > file 67178496 > > > pgscan_proactive 0 > > > # echo "64M swappiness=max" > memory.reclaim > > > -bash: echo: write error: Resource temporarily unavailable > > > # cat memory.stat > > > anon 208896 > > > file 67178496 <- page cache untouched > > > pgsteal_proactive 0 > > > pgscan_proactive 0 > > > > > > Fix this by bailing out early when SWAPPINESS_ANON_ONLY is set and no > > > anonymous pages are reclaimable, before falling back to file reclaim. > > > > > > [1] https://lore.kernel.org/cgroups/7ddf3eee-5fe2-45f7-8614-c8936a039e04@linux.dev/ > > > > > > Fixes: 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim") > > > Suggested-by: Qi Zheng > > > Acked-by: Shakeel Butt > > > Acked-by: Johannes Weiner > > > Reviewed-by: Muchun Song > > > Reviewed-by: Qi Zheng > > > Reviewed-by: Barry Song > > > Signed-off-by: Ridong Chen > > > --- > > > mm/vmscan.c | 24 +++++++++++++++++------- > > > 1 file changed, 17 insertions(+), 7 deletions(-) > > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > index 35c3bb15ae96..2c689682b952 100644 > > > --- a/mm/vmscan.c > > > +++ b/mm/vmscan.c > > > @@ -2501,6 +2501,23 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, > > > enum scan_balance scan_balance; > > > enum lru_list lru; > > > > > > + /* > > > + * Proactive reclaim initiated by userspace for anonymous memory only. > > > + * SWAPPINESS_ANON_ONLY is set only on the proactive reclaim path, so > > > + * warn if it shows up elsewhere. When anon cannot be reclaimed (e.g. > > > + * no swap), bail out instead of falling back to evicting file pages, > > > + * which would violate the anon-only semantics. > > > + */ > > > + if (swappiness == SWAPPINESS_ANON_ONLY) { > > > + WARN_ON_ONCE(!sc->proactive); > > > + if (!can_reclaim_anon_pages(memcg, pgdat->node_id, sc)) { > > > + memset(nr, 0, sizeof(*nr) * NR_LRU_LISTS); > > > + return; > > > + } > > > + scan_balance = SCAN_ANON; > > > + goto out; > > > > Rather than warning the code would be easier to understand > > (SWAPPINESS_ANON_ONLY implying sc->proactive is very subtle assumption > > that might change in the future) I would go with and explicit check. > > > > Looking at how the code is structured currently doesn't the following > > express the intention slightly better? > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 35c3bb15ae96..4fd38e3f1b05 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -2503,6 +2503,10 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, > > > > /* If we have no swap space, do not bother scanning anon folios. */ > > if (!sc->may_swap || !can_reclaim_anon_pages(memcg, pgdat->node_id, sc)) { > > + if (swappiness == SWAPPINESS_ANON_ONLY && sc->proactive) { > > + memset(nr, 0, sizeof(*nr) * NR_LRU_LISTS); > > + return; > > + } > > scan_balance = SCAN_FILE; > > The question is whether we should allow falling back to SCAN_FILE > when swappiness == SWAPPINESS_ANON_ONLY and !sc->proactive, if 201 is > ever allowed for non-proactive reclaim in the future. I guess not, > since SWAPPINESS_ANON_ONLY literally means reclaiming anonymous > memory only? If we follow swappiness==0 then yes we should fallback if we are close to system OOM. Now arguably SWAPPINESS_ANON_ONLY is a wierd global policy and it is quite possible this will not be ever allowed. My argument was not to prepare the existing code for that. I just meant to structure the code in a way that it current assumptions are more explicit. -- Michal Hocko SUSE Labs