From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (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 8C9DF378814 for ; Thu, 23 Jul 2026 13:55:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784814945; cv=none; b=Tm3VM+zMWSZNIU3IMs2gNPNP9nsvXhNMJ+B2u49jMTsewsrBUNGCKY7cN5YV7oc0hRA9lvCVagUs1gjYYHxF/l050m4yTvjXI67ReiAraLc02sXBT9SC3P147fWTLkYZI4HCBuopY+GfPiLi7JckgvoefvZyGR2wC9JeV9Uxkz4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784814945; c=relaxed/simple; bh=PcGnm1nhz6OalWAM+8OBPe0bj+kN8RMGxEyp2+pu2/c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=isDQyvi1bTa4Nzf46+oEgOJG+Q0vUCf+pKZng1tg4mc+Uj1PkggQ3f0rvKZKo/btcRvUmI4wDARa4hkI6JUD5ZiWZPi8Cbg7EAdO1VUmyjzHgpeNFOBljXptkuIfmsVCEby7OPhrKEqqSbbgQ2pLV5TGVRR+0pim9XcE/njCMZA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=nwctVBKE; arc=none smtp.client-ip=209.85.219.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="nwctVBKE" Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-8edda5d56a5so7867706d6.3 for ; Thu, 23 Jul 2026 06:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1784814935; x=1785419735; 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=JdlTjNa72Apcdo/QV8cbG21bSLdkYHzKHF8zUNaq1xI=; b=nwctVBKEkGTqB3NYBl1O1N6NbT3IS5MRJDoijb4VSpGBHqhMtzQRvoAUEYWxEfCRAJ EeyzbPOlL2rogqwSdr3AXBL5WWl6RSMyAoIdpOWzINHvrcOF6JHtqEUpGRTwuADTEr5C c6rYRqmIdzQsee2aYu7HTOdCyxz0ubacwoPL5fSEatVEQdCT4EoOC0zmJoPBKCnm2aCW kz+/xgtp+r4Is9Ffo5EWOaC7TnZhll8Qdyu0eQYWzcWU3z+zPN3ZyPVqHsx9r2pqiGwW TeiVC075M3giH+B9PCeWWIKG979nYU2wObisX0eu0ZTEEVk7p6ja26/LyA7HC4FiCfdr icJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784814935; x=1785419735; 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=JdlTjNa72Apcdo/QV8cbG21bSLdkYHzKHF8zUNaq1xI=; b=YVVxHc/KA546ZfUk/36plhxtQcHceI+12pSK4T3Y/KiBd7bO3d2w8cu/KQai26qpwS V8TmnWKfXFYnykuWaqu+jAiR8TxpYXquZNl0oN9sFEmzoJj3UAl4uMIqsyhEmUj5XB86 YuGMAOQnW7RVSejs4hrXJcjC0hgZL/AoV1yv6pI1StAR7CeiUoH4AXtOgRPx2MqFdoJ/ Q3KB2B8TPyfExg36lr4OhCwza5rv3z0NW6Z/XcR8XDfwcYvDEUE2I+fYKazheaCweju/ toMrBslPZnF2NZeW7EZYtsNJuC59QTR8Tap0B/LLFb8gcqrSrN/VdLZUa0IaOEzO3rSJ VENw== X-Forwarded-Encrypted: i=1; AHgh+RpbNtvpH7yxKrYmrZ8e5R082hiRroB2LZgrho+JWE7YPlju1/bK/bYGEI+UWxh4j48zOuTiuJzYTecyvsQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxhYlofX4w/oMOL49KLw9/jNDsvf6c4DKUNvBQAI3gl1cgCMVop mHCL9eVRNisEJR031FcGc6cw7m8uIW0ZnTySbvYxb40qa1vQjuvJTpp+aX5T8br97Jw= X-Gm-Gg: AR+sD11BmgUXcJL0779udQECGV4o1+gmQWAmUxaJEtyJUKQg75mAF7CFhTn07jvALdS J1PIeUvuLmDqeqZrq/Rj13ti2H0qreky8whNJg1v6925LdGzQqB2JaQLyQom45NJ/3lScxDYV56 wYFfgJUS7ZMVCp8HJFlyKkfMn8eB73iLUxItRroVgWuacpvI6hL9DGpc4icarmzKBJFtP6w+gxo k9VJZCIol3r1yqxqp9rd25ESZ0+8HFGGSuDarVG+UjtVOasrgPfFfjX+myXWOwX1cj+Ivmzbcyo lY6etxrr4sRn49WXrk3fvdIMIEwj5cu8ROkzlXFhevTjl7srsSAb9VgX1ll2g31H+dxW3XpizH/ 5zCASeT9iSrqr4GVZoWxTmJ+4cNL4ZjY6Z4NWD/ThVSBpkN3EvstsCmE/HD8G/CkMYsVHU/J1iR f7 X-Received: by 2002:a05:6214:40d:b0:8ef:e3c9:5336 with SMTP id 6a1803df08f44-907ca356302mr35958626d6.34.1784814935519; Thu, 23 Jul 2026 06:55:35 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-907baa27cfcsm45192186d6.44.2026.07.23.06.55.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 06:55:34 -0700 (PDT) Date: Thu, 23 Jul 2026 09:55:31 -0400 From: Johannes Weiner To: Yosry Ahmed Cc: Hao Jia , akpm@linux-foundation.org, tj@kernel.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 Subject: Re: [PATCH v2 2/2] mm/zswap: Support batch writeback in shrink_memcg() Message-ID: References: <20260717085151.22822-1-jiahao.kernel@gmail.com> <20260717085151.22822-3-jiahao.kernel@gmail.com> 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 Wed, Jul 22, 2026 at 09:52:18PM -0700, Yosry Ahmed wrote: > On Wed, Jul 22, 2026 at 7:27 PM Johannes Weiner wrote: > > > > On Fri, Jul 17, 2026 at 04:51:51PM +0800, Hao Jia wrote: > > > @@ -1369,7 +1402,7 @@ static void shrink_worker(struct work_struct *w) > > > goto resched; > > > } > > > > > > - ret = shrink_memcg(memcg); > > > + ret = shrink_memcg(memcg, NR_ZSWAP_WB_BATCH); > > > /* drop the extra reference */ > > > mem_cgroup_put(memcg); > > > > > > @@ -1493,7 +1526,7 @@ bool zswap_store(struct folio *folio) > > > objcg = get_obj_cgroup_from_folio(folio); > > > if (objcg && !obj_cgroup_may_zswap(objcg)) { > > > memcg = get_mem_cgroup_from_objcg(objcg); > > > - if (shrink_memcg(memcg)) { > > > + if (shrink_memcg(memcg, 1)) { > > > > Why 64 for the global limit but only 1 for the cgroup limit? That > > seems arbitrary in multiple ways. > > I suggested that we keep the writeback here without batching and do > that change separately, mainly out of abundance of caution as > writeback is done synchronously here so the extra latency could be > problematic. I think we probably want to measure the performance > impact of that separately. > > That being said, this path is potentially too expensive anyway due to > the flush, but I would rather we do some basic measurements before > batching here. > > What do you think? It's not an unknown, right? We know this works for direct reclaimers, cgroup limit reclaim e.g., and what the latency implications are. Because of how reclaim works, we also know it'll call zswap_store() in batches of SWAP_CLUSTER_MAX. If we don't batch here, they're likely to each call shrink_memcg() once we're at the limit - while still risking rejections due to compressibility differences. My worry is that if we start with an inconsistency, we'll be stuck with it for a long time. I'd rather start with the clean, consistent version. Dial it back only if we have data to justfiy the complication that we can put into a comment and the changelog that outlines why exactly it's different.