From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta0.migadu.com (out-170.mta0.migadu.com [91.218.175.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 393AF33893A; Fri, 6 Feb 2026 17:53:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770400381; cv=none; b=Rmn6mQk896Sv1lNgeMnk1RdojSFigPcRjeu8g+xcHcI42YKx9NgEy2Ih8qFGW858KIbYK5eVvExZfB1GR5AdpBA+LPiAAgvb0wtbvNVt3fGyVxDCXGbEuQWdYeXL1w3XjmWEQp+jaWVrS9fW82wLj30IZkBCuGYtQMndz629nlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770400381; c=relaxed/simple; bh=pY5ju9pn92zusS9+/KKoBWqSlGsJaJH7q0Nebo59Las=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k9wpeZ46HEaN7yb6mniYKBNVTRvvIkU5HZBk8/HG3UqriXSL9Q0rGiIn2+RbFuVxUR9MONZT3SDhZUnUdOD+EZnohrNOdolOZdSg0ztcXKq9wtOuFlVWPA8FQu9Q25q2ut55mufOx4RbY/+qcoCzejlLaldJja03YY0bE69j+Gg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=NNOcaFy2; arc=none smtp.client-ip=91.218.175.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="NNOcaFy2" Date: Fri, 6 Feb 2026 09:52:43 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1770400369; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iglojX4sGUyAtQslTyBLFp6CalS9+S4aj8OW0MG/LxI=; b=NNOcaFy2R2zTQsGUVb+84nFaFJk+vqlHDL7Z3ZTYWxk4WpcnHwDLyQW0yB6ehur4GHdHOU ZfLbAOGmvNb0kDL+ELwCJ3W8PD3zO4+OBRsoqUhpmdyCiiTYsDsGp+P1kFPc23CWTJJgCa sX7Mt5vlWWf+lNfPNbUX+XoboaSYV/M= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Jiayuan Chen Cc: linux-mm@kvack.org, Jiayuan Chen , Nhat Pham , Tejun Heo , Johannes Weiner , Michal =?utf-8?Q?Koutn=C3=BD?= , Jonathan Corbet , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , Yosry Ahmed , Chengming Zhou , Shuah Khan , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v2 1/2] mm: zswap: add per-memcg stat for incompressible pages Message-ID: References: <20260206072220.144008-1-jiayuan.chen@linux.dev> <20260206072220.144008-2-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260206072220.144008-2-jiayuan.chen@linux.dev> X-Migadu-Flow: FLOW_OUT On Fri, Feb 06, 2026 at 03:22:15PM +0800, Jiayuan Chen wrote: > From: Jiayuan Chen > > The global zswap_stored_incompressible_pages counter was added in commit > dca4437a5861 ("mm/zswap: store to track how many pages are stored in raw (uncompressed) form in zswap. > However, in containerized environments, knowing which cgroup is > contributing incompressible pages is essential for effective resource > management [1]. > > Add a new memcg stat 'zswap_incomp' to track incompressible pages per > cgroup. This helps administrators and orchestrators to: > > 1. Identify workloads that produce incompressible data (e.g., encrypted > data, already-compressed media, random data) and may not benefit from > zswap. > > 2. Make informed decisions about workload placement - moving > incompressible workloads to nodes with larger swap backing devices > rather than relying on zswap. > > 3. Debug zswap efficiency issues at the cgroup level without needing to > correlate global stats with individual cgroups. > > While the compression ratio can be estimated from existing stats > (zswap / zswapped * PAGE_SIZE), this doesn't distinguish between > "uniformly poor compression" and "a few completely incompressible pages > mixed with highly compressible ones". The zswap_incomp stat provides > direct visibility into the latter case. > > [1]: https://lore.kernel.org/linux-mm/CAF8kJuONDFj4NAksaR4j_WyDbNwNGYLmTe-o76rqU17La=nkOw@mail.gmail.com/ > Acked-by: Nhat Pham > Signed-off-by: Jiayuan Chen Acked-by: Shakeel Butt