From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (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 DD84A2BAF7 for ; Fri, 6 Feb 2026 02:04:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770343475; cv=none; b=ugV5gFNz0IQ8FbrBtyFGeC2HLWJ7M6lKTP/uF5U3ZjSEhe5PHMYH68c4pRkgnFn4oF2V05AXCpWgO2+vq1f1cj9htE+6pUTSz1ub6rgljl+Iu5RD7qJSbkRyOCmMEeGVHmIzclsKjzk+kUpgSCq8IuZ5uwSmRdOwEfvdZTLj6es= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770343475; c=relaxed/simple; bh=N5f/JJXQeV/JKEH2r9goubdllnd8Ai7KxS7/BidLxAc=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=uDBavdfFqogoCekNWEEl9oXvCP1uI0GtziP4elNmL5K21oBXFZKF73HKaM0cHe8dRPINWHD9/WpalQRq5ct9owHcilhyq4SQuvLiiN6NK+jN9fn/H0590cVF+hHl2Xv0aYqCeybW9wWGQ1twY7DpaK6CseMNJsBdP7jfOCYhOxI= 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=NNFkOUfS; arc=none smtp.client-ip=91.218.175.178 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="NNFkOUfS" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1770343462; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tQFK9n1X/6XJOHaia/NkQdjYqZ2VqcclwuM3/PMBkl8=; b=NNFkOUfS6OjPT6fWDsTe8LgVnn2qNou7cPBmDkWDv7x//qYHO6stl5mJ5r0B4GeKs70HAL wzY5Yjx85rWtUN60++ZAzx29NyH3RDJ/3/4Hv3I5GefX+rOYOYVTGk2S7FvteQ5OvypsTi kQ+ozs/7Y8wzKp1gzgw9uVuMZ/0S7BE= Date: Fri, 06 Feb 2026 02:04:16 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Jiayuan Chen" Message-ID: TLS-Required: No Subject: Re: [PATCH v1] mm: zswap: add per-memcg stat for incompressible pages To: "Nhat Pham" Cc: linux-mm@kvack.org, "Jiayuan Chen" , "Johannes Weiner" , "Michal Hocko" , "Roman Gushchin" , "Shakeel Butt" , "Muchun Song" , "Yosry Ahmed" , "Chengming Zhou" , "Andrew Morton" , "Nick Terrell" , "David Sterba" , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, "Chris Li" In-Reply-To: References: <20260205053013.25134-1-jiayuan.chen@linux.dev> X-Migadu-Flow: FLOW_OUT February 6, 2026 at 01:45, "Nhat Pham" wrote: >=20 >=20On Thu, Feb 5, 2026 at 9:31 AM Nhat Pham wrote: >=20 >=20>=20 >=20> On Wed, Feb 4, 2026 at 9:31 PM Jiayuan Chen wrote: > >=20 >=20> From: Jiayuan Chen > >=20 >=20> 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 zsw= ap. > > However, in containerized environments, knowing which cgroup is > > contributing incompressible pages is essential for effective resourc= e > > management. > >=20 >=20> Add a new memcg stat 'zswpraw' to track incompressible pages per c= group. > > This helps administrators and orchestrators to: > >=20 >=20> 1. Identify workloads that produce incompressible data (e.g., encr= ypted > > data, already-compressed media, random data) and may not benefit fro= m > > zswap. > >=20 >=20> 2. Make informed decisions about workload placement - moving > > incompressible workloads to nodes with larger swap backing devices > > rather than relying on zswap. > >=20 >=20> 3. Debug zswap efficiency issues at the cgroup level without needi= ng to > > correlate global stats with individual cgroups. > >=20 >=20> 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 pa= ges > > mixed with highly compressible ones". The zswpraw stat provides dire= ct > > visibility into the latter case. > >=20 >=20Actually I forgot - can you also update the Documentation: >=20 >=20Documentation/admin-guide/cgroup-v2.rst >=20 >=20to include a short description of the new counter? Thanks! > Thanks Nhat for the review and Acked-by! I'll update the documentation and add Chris Li's link to changelog in v2. Will consider the selftest as a follow-up.