From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 7D4ED3F54CA for ; Thu, 16 Jul 2026 18:19:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.221.53 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784225944; cv=pass; b=D8NTU3w8D+LKGcj0WCP0D7qnqGtVINO36GWBtE2I/lg1CkBbSpIOmbAWWMOuDrhM2RSb8f3vU5ngPrZ9BBocUSTkrbtDepbBvNY1QUKyU0EePXuVbe0U3yJ8/CglWo28N7KIajDGpVsJ6t5dssXdfv5IvzJ3PJ/479NkI1nIQGU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784225944; c=relaxed/simple; bh=40CP3ck5nVy6QPOWWJBMR4rjP7Y/oJjXJIQelgpWKGg=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=DPpt6TS0CKdFHRE293x/UM6kBKiWK875ecykZfZ6BckxgKZAEfeSuhObgYXzOYI3LLH4L5TIZ5/ohZV7QmCQ99dildhF++YSjl53nPuqiZKzOgwLVnEkVrRth2rjP/5foqk8TbD83aG1hhEqrVA+3oqoOBSK7jEmIdVcHxGqScU= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=e7dZtMHV; arc=pass smtp.client-ip=209.85.221.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="e7dZtMHV" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-475417f010dso3615815f8f.2 for ; Thu, 16 Jul 2026 11:19:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784225938; cv=none; d=google.com; s=arc-20260327; b=O1QQmEltKWD8kmkmQixlDt83LRLfKNSwUmvZ+2wPk9m6SaKCnNDe2Q63xH2KdT2+Ul o08EJRhDYQRyrKqSDoe5h8dCM07xfUoxdIo57yRp9aN4ZbOy/JoMwYbPnjmB6svpJHLx ICw3grwrJa6LsT5TEKKSIqICmWyR73kovjj/JHtInVDvYefl8AGfRpDLYCjN/H4YVnnE c0Fm7u0zNXDWwE8cbYtcHEABedg3CcfbZUqS1CibpYWsj14S+eOXZzfp7tAbevBnYqk3 4XOZam2RSXOk3VpO4ycsRLvOPWiuG+nngquxfkLfq8wh1QAt35y+XTii4n2uDHrYnGqz JK/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RCJWw44Yt9QfTMjmF/5pzznV1wMqLVnfAfzAdUp6RWc=; fh=pBZXQNQadzRykGwbPQygMEkbh7GS2qZK6X/kYDA7HRg=; b=H6quPZ7yv8wPnOCk+poVxddf30LcvJBt44o8hEI0y/8BF1t1jbq1xcjxcv1g5UTtT4 MJpYvSSSvRmdgpJ5LumXAlBv0/Ba379HcOVeXO9Q+fXJEmrAohBPOK8nHvu+rUXHg2M2 feK0KLAOxpM2INRGBnu2Bu7o7m+LwV4pvgxUwYRLpdVdygbjXvk5PE2TLKxVQDXuZdQs VYj7fHdimIlkpz2xCplO1AKtWkKHcf6VVUrbjkBIcOIBwNEvuZll575gH0bfD8qQ/BVN 5KjHyA9K10WR1gJ0FH167DcUTZciK2dKNDkM170kd5zeotFi02LPdWyYWcCNu+vws0y7 znoQ==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784225938; x=1784830738; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=RCJWw44Yt9QfTMjmF/5pzznV1wMqLVnfAfzAdUp6RWc=; b=e7dZtMHV8W1WFXBv5njNMIwwKMR4ccU2LNIzI4y3USlM6Uebp6GpnVuEoff70Kb0a4 WlsrxK4epVDfdSiGUDWFe668OJe6s2/Rn4O7fj4E2mqNknwHKetLY7fhQjgJazOAHF6T TKVAT4/jS1bt/sKweV085w0Jsn+/dFbleu1CQ2YMyOuBg/T7rJ1ansjHj/t6ndqyBhIj AJoHAvxeFIZCL9oLNqIVvDWV729/AAQAKc03sz9lupckCSkckcmrhAObDXpdZdvvEego 6RtoOVkv2Cj4YCTQ5p+Z9OadJq9d6ZlgYQlz8xIZizciykkJIC4fc9tb9aY5YC0zw5mm ydKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784225938; x=1784830738; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=RCJWw44Yt9QfTMjmF/5pzznV1wMqLVnfAfzAdUp6RWc=; b=WV7Quq6X3kHoB3Is5XUfLIyiBKcrpW8G9h5SIWE47C0ChbEHmHNp3SSP76MTIdovlN 7VEfsTD/7u2XkArAt243EPYq3nAmU0NB3wlNJctn+xyaWDOk6n086/fM9HuNFtV6QC18 SBPFvxW+gO7eB33Hvc2XfZiPrk7LmZ8uB5TXWfHEsdzAN42GdT2aqW1PST7f/ZspCYPY liv9wMcWNd8XHsVjkiw7bWqUT+d1QugpbTt62N7DBKBglahZkhOD2MVPDBU3lyakfGzA vSnqPx5KTEq850x+Ab9UPlF5y1rvQ7osy6WudizsNwMVTQd/uB1kKM902nT1NCnWak2b cg+Q== X-Forwarded-Encrypted: i=1; AHgh+RoEeF5daFpCPLca7xfSYYyaYDK/7a0ARODtkycLn1CS2lXaflkNaAncJXoHiViP4Nuy3iNeEHvabvLqoM4=@vger.kernel.org X-Gm-Message-State: AOJu0Yxd6InsEobUjUeLhA1AuQ7IPI+ojU2pFR0gxC1p3a+r63gU4OWC kwIAAwiTLPrMqJhhb1O7PXS5w12y/Ape1ODsAMF7qKIknp7KqbIZvgoWYTaox+eyjGvYq1Y55lm tBj+Suru03cGksB1LdffneT0olXvQYjIoFN6E47F8FA== X-Gm-Gg: AfdE7ckhhlncTeDHGVGje3e3V3vpxMsCynXj/1Sms+uO0UOP9O6uN0B2DRGaHt+gxEA K7DBRUv5mzC1sLz0BRrB97TgK2TJryNst6qj6yb1L+dLmq73oRKysz1ba7fi4AwzBu/cXM6K7wd DsNEfCR+jesjEVrecZr10GYpJ2coIlnHPjnBGpTwozyfxyedLPFsrNul1jKX6Sb6E75e4q/AYq7 ptrwd1+fCKVGMkG0vz+Z7Q1J0z6oQLAjrmSKBpi+KqtfuELUCLBcFk/eaendXf3/g+h+c5/Sfbj fMvpizjBLEQs8FEFfZKGT8UnDG112Ci8Wg== X-Received: by 2002:a05:6000:490d:b0:47d:ec60:657e with SMTP id ffacd0b85a97d-47f4fcd91c0mr9789980f8f.39.1784225937975; Thu, 16 Jul 2026 11:18:57 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260714081510.16895-1-jiahao.kernel@gmail.com> <20260714081510.16895-2-jiahao.kernel@gmail.com> <20260714193129.f81711f516504b659d544741@linux-foundation.org> <7a1fe347-7ca6-4768-9308-420bf1251f54@gmail.com> <7b35fd4e-7662-10ae-159b-303350e4e59c@gmail.com> In-Reply-To: <7b35fd4e-7662-10ae-159b-303350e4e59c@gmail.com> From: Nhat Pham Date: Thu, 16 Jul 2026 11:18:44 -0700 X-Gm-Features: AUfX_mxIpAby5cOyODbdsd_vYnsokVJLS1QcOfP3fFXU1u6G5EgnSr-TbOWYryE Message-ID: Subject: Re: [PATCH 1/2] mm/zswap: Fix global shrinker when memory cgroup is disabled To: Hao Jia Cc: Yosry Ahmed , Andrew Morton , tj@kernel.org, hannes@cmpxchg.org, shakeel.butt@linux.dev, mhocko@kernel.org, mkoutny@suse.com, chengming.zhou@linux.dev, muchun.song@linux.dev, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Hao Jia , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 15, 2026 at 7:21=E2=80=AFPM Hao Jia w= rote: > > > > On 2026/7/16 00:13, Yosry Ahmed wrote: > > On Wed, Jul 15, 2026 at 5:31=E2=80=AFAM Hao Jia wrote: > >> > >> > >> > >> On 2026/7/15 10:31, Andrew Morton wrote: > >>> On Tue, 14 Jul 2026 09:52:59 -0700 Yosry Ahmed wro= te: > >>> > >>>>> When memory cgroup is disabled, mem_cgroup_iter() always returns NU= LL. > >>>>> Therefore, the global shrinker shrink_worker() always takes the !me= mcg > >>>>> branch. After MAX_RECLAIM_RETRIES empty walks, the worker simply gi= ves up, > >>>>> so it fails to write back anything. > >>>>> > >>>>> Therefore, when memory cgroup is disabled, fall through with the !m= emcg > >>>>> branch and shrink the root memcg directly. > >>>>> > >>>>> With memcg disabled, shrink_memcg() only returns -ENOENT when the r= oot > >>>>> LRU is empty, which means the total pages are already below thr. Th= e > >>>>> loop then safely bails out via the zswap_total_pages() <=3D thr che= ck. > >>>>> For any other return value from shrink_memcg(), the loop is guarant= eed > >>>>> to terminate, either after MAX_RECLAIM_RETRIES failures or once the > >>>>> threshold is met. > >>>>> > >>>>> Fixes: a65b0e7607cc ("zswap: make shrinking memcg-aware") > >>>>> Cc: stable@vger.kernel.org > >>>>> Suggested-by: Nhat Pham > >>>>> Acked-by: Nhat Pham > >>>>> Acked-by: Yosry Ahmed > >>>>> Reported-by: Yosry Ahmed > >>>>> Closes: https://lore.kernel.org/all/CAO9r8zPVzMKFbCixxD-qgtRrkFxWVr= HiZZeLc=3DeyTPKPVQgX4g@mail.gmail.com > >>>>> Signed-off-by: Hao Jia > >>>> > >>>> Patch 2 doesn't really depend on this one, right? > >>>> > >>>> If that's the case I think this can (and should be) picked up > >>>> separately as a hotfix. Andrew, WDYT? > >>> > >>> Please update the changelog to clearly describe the userspace-visible > >>> effects of the bug, thanks. > >> > >> I am not entirely sure if my understanding is correct here, but maybe = I > >> should add something like this to the commit message? > >> > >> When cgroup_disable=3Dmemory is used (or with CONFIG_MEMCG=3Dn), the g= lobal > >> shrinker fails to write back any pages. Consequently, the zswap pool > >> fills up to its limit and rejects further storage, preventing memory > >> pressure from being offloaded to the backing swap device. > > > > I think you can simply write that zswap writeback when the limit is > > hit is broken when memcg is disabled. > Will do. Thanks! > > > > >> > >>> Also, AI review has flagged several possible issues, all appear to be > >>> serious: > >>> https://sashiko.dev/#/patchset/20260714081510.16895-1-jiahao.k= ernel@gmail.com > >> > >> For AI review comments on this patch: > >> I suspect this scenario might only exist in theory. For zswap LRU to b= e > >> empty while zswap_total_pages() > thr holds true, it would require a > >> prolonged state where there are always more than thr zswap entries on > >> the zswap LRU whenever zswap_total_pages() > thr is evaluated, yet the > >> zswap LRU happens to be empty during shrink_memcg(root_memcg). > >> > >> If we want to fix this, perhaps we could do something like this? > >> > >> Yosry, Nhat, what are your thoughts on this? > > > > Do we need to do this? The last paragraph in your changelog explains > > why this can't happen because zswap_total_pages() should be 0 in this > > case. Did I miss something? > > The loop would require the following sequence to repeat indefinitely: > > 1=E3=80=81zswap_total_pages() > thr evaluates to true. > 2=E3=80=81During shrink_memcg(root_memcg), the zswap LRU is concurrently = drained > to empty. > 3=E3=80=81Before zswap_total_pages() > thr is evaluated again, the zswap = LRU is > heavily refilled such that zswap_total_pages() > thr holds true once more= . > > For our case to manifest, it would require zswap_total_pages() and the > zswap LRU state to repeatedly hit this exact window with perfect > alignment over a **prolonged period**. Therefore, I suspect this > scenario might only exist in theory. Yeah seems very artificial indeed. If we want to be extra careful here, maybe we can put a cond_resched() there or replace the continue with goto resched or sth?