From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) (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 361E743B6E3 for ; Wed, 15 Jul 2026 11:28:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784114903; cv=none; b=TasSEDCqc3JzvDSQpWJ01HKDUy3q3ioSs5Ww9jfSXvjHV3vOKnxFzaGFadkJ0pZFwISe7JfBIWILS0DwdkqtOCjMjl/7f2hf6Cv9AK1hUfvzEP7wgSVoUQ0dbAa2DQnxZ5EHNDJde6LeGvVCR+ddU7fKjWNjpDexKo+G9/gfldU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784114903; c=relaxed/simple; bh=tqvNLaV6+k1iAJaLbwpkKc68DEDWnWGXhZHCaF65ZjI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=V8PhbdIw+rPWAjP8a7Xv5WuS6fkwMtTVDYnZqGqxfHzhRFx7QsDrY/hEfL6XmneXALOLjvfIpUeH74PXhVz56P+GdjoSSoJBUvMdCYAs9uwWb2kMlejKpKYOeHH0ryzU1FNDnfvVYtzYkH1cc8yx5LBR/zqv+26O1QyY3W4Si28= ARC-Authentication-Results:i=1; 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=S4K4ImUp; arc=none smtp.client-ip=209.85.215.169 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="S4K4ImUp" Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-ca913a601fbso3728997a12.3 for ; Wed, 15 Jul 2026 04:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784114901; x=1784719701; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=BjZpJ/ZGdtH4VffFiXS+PfV8IVOQCwOAwF8cWS5dH18=; b=S4K4ImUpd901IlbKNjo72LJkDPR5GMcVt3LY7po9/HHrg5Dybazpw0W2zTW1cOobII P8L5RcGznCG6lmkStVTCfCQnJGkV+sAFAzomS0sYZlBp43vGY3mZrimj1+hccFFUOq+6 S8jj8qSHWkyFFmSZYOm7nBKOceQ73X7bo4SjBNFgYQPfZcGLgKSfX/bEwupA8gumxXVe 9sXk6CauNbmvsIFnm9WHMskdBbe9Z+m5/XyHqZbLxj1y8fsOcdis0m8UlOVmmHdfYLsM j1lMug+7/iKBC8dYol3/lVSDtILYpGA4fUVHeIBWmDVlkvXnNerzh12cjIztykF8+sYJ UGYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784114901; x=1784719701; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BjZpJ/ZGdtH4VffFiXS+PfV8IVOQCwOAwF8cWS5dH18=; b=kw6+wIMJ04OYAMetnbC6GHPTOyUNQcS9Zmo+KdcR6XV5SF+uHg46zNDnR4wvU4dKiF l1shOVVhhgZKbbv9NPSb748pKWXZx6qmz+sy8TD11mHzLYA2DUqt2+CQN5SBmsX0L9LL OdrpEdMpaJSHl01DtsofNOZgIIfFDFAobscbj7p8auoDiEWAiL6J2ganGRar0oClKGhs HoPRo6wpbLdP0NgQYv7ZVMZ/Bl3qGAlGK9UoKdQR4I2snkaxWBv5lke2yujbjAeeDlZx rRlsVFQHWNfj42Vqurdcrd0fwe1rC+gu2bRznJyPbA3mpZRmi9KorpCET1D3p1RnDIj4 OQIg== X-Forwarded-Encrypted: i=1; AHgh+RqH6qsO6tsSLBdQCu0yraNSuVIRKwmN7aBP7IxgjuSboDXnDeMA0OQQQpsX2z0HGMWkg0oNgm5aysX8PLc=@vger.kernel.org X-Gm-Message-State: AOJu0YyNfDyXfQa6ZY+C7bIjvdjetinGvBjm/m5ceWACPI7T2VWjez/5 3ekmMS80NB9Ato9XAN2RYZUaza5WgmJF/TGrqeg2KxGZO8x4Zi0gnHzz X-Gm-Gg: AfdE7clCEyV/HiZj1zseacrviJPtjiL9wFhLAxNDXhZoINSKQwEKJ58i+UzNnedk81u AITgjlnuG5e+nMQNlTR9nv4iZH3D8k6iEctcV0daHfc3Ud8GJ+8JC5xeAZRSaylv5myRHy7Ow/e FA0Q36SBb3UK503dVJPlbvy6mw5d8boz0elQfKknnSLqHVL3ykehMgoZqy27+npg7W1v5qzbZmH yP2ueVZkruYzgFM8HIC+Suvfes3zDZEsSnbe0AevB/UdQnj5hgETR2jnNkhss2iYIn5umahECMH 3HnsBgi/J+qvp+k7MFQh6hmrB0OYENbliU0JdNHXIUrPetPgqjKkXEzouNYFhLrwVLROZNjtGGN ZEigUzlJqc4RwOZwPrOv/oNQR9z4slzpgsG4ldQ92mXjsHxjbU8GIuYYVti6x/eRzY1R/RJptUN AzOC8J7QzxOn/t1lD4bSVdDqQ8auwDZ98/Kw== X-Received: by 2002:a05:6a21:730e:b0:3a2:d838:bfc6 with SMTP id adf61e73a8af0-3c3573f6e82mr7065531637.29.1784114901393; Wed, 15 Jul 2026 04:28:21 -0700 (PDT) Received: from [10.125.192.114] ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cb258fcfe20sm59594a12.15.2026.07.15.04.28.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jul 2026 04:28:20 -0700 (PDT) Message-ID: <2bc8e4f6-46a0-5b74-6eaa-59e7aef9227e@gmail.com> Date: Wed, 15 Jul 2026 19:28:10 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH 2/2] mm/zswap: Support batch writeback in shrink_memcg() To: Yosry Ahmed Cc: akpm@linux-foundation.org, tj@kernel.org, hannes@cmpxchg.org, shakeel.butt@linux.dev, mhocko@kernel.org, mkoutny@suse.com, nphamcs@gmail.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 References: <20260714081510.16895-1-jiahao.kernel@gmail.com> <20260714081510.16895-3-jiahao.kernel@gmail.com> From: Hao Jia In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026/7/15 00:52, Yosry Ahmed wrote: > On Tue, Jul 14, 2026 at 1:15 AM Hao Jia wrote: >> >> From: Hao Jia >> >> Currently, shrink_memcg() writes back at most one entry per-node during >> its traversal. This makes shrink_worker() inefficient, as it must >> repeatedly re-enter shrink_memcg() to make any substantial progress. > > Please also mention the case about writeback being slow to keep up > with refaults in some cases, leading to zswap store failures and pages > skipping zswap and going directly to disk, which is an LRU inversion. > Will be done in the next version. >> >> To address this, extend shrink_memcg() and rewrite its LRU iteration logic >> to support batch writeback. Introduce the nr_to_scan parameter to bound how >> many pages are scanned per call. This enables batch writeback in the >> shrink_worker() path, while maintaining a low scan budget in the >> zswap_store() path. >> >> Additionally, to prepare for future proactive writeback, update the return >> value semantics of shrink_memcg(): a positive value now represents the >> actual number of compressed bytes written back, 0 indicates that candidates >> existed but no writeback succeeded, and a negative value represents an >> error code. > > This part should be dropped for now, and added with the proactive > writeback, as it's currently unused AFAICT. Removing > zswap_shrink_walk_arg will simplify the patch and make it focused on > the batching part. Will be done in the next version. > >> >> Test Setup: >> Total memory: 32 GB. >> zswap settings: max_pool_percent=1, accept_threshold_percent=50, >> shrinker_enabled=N. >> Allocate 512MB of anonymous pages and fill them with random data (to avoid >> compression), then use cgroup memory.reclaim to force a large amount of >> anonymous pages into zswap. At an interval of 2ms, allocate a 4K anonymous >> page where the first 4 bytes are random numbers and the rest are zeros, and >> then trigger a reclamation of this 4K anonymous page through cgroup >> memory.reclaim. When the pool threshold is reached, shrink_memcg() will >> be triggered. >> >> The test data after running for 120s is as follows: >> Baseline Patched >> shrink_worker wakeups 5363 85 >> shrink_memcg calls 11,345,012 188,264 >> written_back 40214 40275 >> >> Conclusion: >> Under the same workload and run duration, the patched kernel shows a >> significant reduction in both shrink_worker wakeups and shrink_memcg calls. > > Please also include data from the case where zswap store failures are > observed and pages go to disk, and compare before and after this > patch. I think that part is also really important. I retested and added some collected information. Perhaps `pool_limit_hit` and `pswpout` can explain that batch shrinking of zswap can reduce the number of pages that fail to be stored due to the pool limit, allowing zswap to skip zswap and go directly to disk. Baseline Patched shrink_worker wakeups 5,363 85 shrink_memcg calls 11,373,201 180,928 written_back pages 40,212 40,236 zswap_store calls 161,190 168,741 store succeeded (ret=1) 102,743 127,644 store rejected (ret=0) 58,447 41,097 store reject rate ~36% ~24% pool_limit_hit delta 55,826 14,062 pswpout 98,659 81,333 pswpin 2 1 Thanks, Hao