From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 4226F1E515 for ; Tue, 24 Mar 2026 12:16:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774354616; cv=none; b=tjte5tNIx0NSmOmSGF56yh9aqENm21XDhKoldgZa/9MQOpD9sGreeZrB0D1oT1rxL2h8dDybxl+7EaOpg/7V06agiC0MUjIUMVUFIKhR2NKE+JRglErrEJHC4I/umsKknr5ZtVN8J/MMNYWgcSsx25WT25VsTpfMsU8YhonTkEU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774354616; c=relaxed/simple; bh=+RaXOIWqsw+n2zcRxpSYHf2lblZVauhGDnf9UUpapKI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OmfVnfWt9A65UCcTadtBLAzjT6zsSjv+bUOke9/B/46mKVz/1UMCsOfa4c4G0YbBLvopPu38JzUKnT+RahM7h1FEMMXZIhMcOU8FjSLHaeAm/pcxkvgAlvwWDU2r6qOa7xiJff8dz5d4ZByiUDL3UoROXsOijUwOkrM4Uk80pew= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=YfS3T7QS; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=OGi8nS5l; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YfS3T7QS"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="OGi8nS5l" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774354614; 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=4OtOkqE5K1/9sgyu+3hID1K7mKq/H1/ijDAgg14kY/I=; b=YfS3T7QSqO1tsStmA1E8/bFkDYl1WNFTPchSwR+83wSIpopGV1C+PNEmeuersshW71iAaa 1N2cTD/qL4T/6VJB8yLVJx2j59PA5AX6np1ptoY0M/c8+fOcImuaEsTz7XN9PFFuu/KYZp FYwzLuwSfAZ/US8OT763QXGFUNLtsQ8= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-446-55f0p7k5PM2wOc2aY0cWkw-1; Tue, 24 Mar 2026 08:16:53 -0400 X-MC-Unique: 55f0p7k5PM2wOc2aY0cWkw-1 X-Mimecast-MFC-AGG-ID: 55f0p7k5PM2wOc2aY0cWkw_1774354612 Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2b06b68783dso26392325ad.3 for ; Tue, 24 Mar 2026 05:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1774354611; x=1774959411; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=4OtOkqE5K1/9sgyu+3hID1K7mKq/H1/ijDAgg14kY/I=; b=OGi8nS5lca0EmSBiUneLLaNRsgTvFyMr535mhPvHJgsUqMkbcucVeSfgVGBac6MwLA K8Gj1v0SroPmBuDQEJWRfVxQMx/zFOWqjeptg+lR2TJxACmfycKBUjyS02QtRx4+BE0m U9Cs203P1d+g2t+8fqAQ+flQOOUHt/FESSyPjm/iPxVG7l9EcruD9oGutbp58IzXDNLY CH1wBfINtYJN5YOa8/aTjuaq8t5lPGM/Vn+3UA0RV+ukWvx87qnFamZD0GPW4U4N1ORS Nq3PuDCHwYHUxzc2Dn67PPI3sZ2st3DZI5UpR5ytnfbpJjOdBAuZ4XOFOp0NHGoi6RQP /wUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774354611; x=1774959411; h=in-reply-to:content-transfer-encoding:content-disposition :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; bh=4OtOkqE5K1/9sgyu+3hID1K7mKq/H1/ijDAgg14kY/I=; b=rN2XrqYlDsshCVv//1s8m4BfH6VqHAyCW9W5NEukNWVG4mFCk9NGK+MYZpPEtlHv5A PnePvAeUPk7W//M3Qmh6sNxBEdE31qXvtUpGfnWgQUKIaOiUTKrLvEBoK/zOrnK/9UDi NgmqZc8xmWJ0a7SFsywju9ZM9r2arD2a1jW7xVRraVyP+e15TcV76c7JjG4m2NonLyeE K4MdX5pXeSnqQap4cl4z6ZlnGu9KZsSLqqBpmL6kfPLNhIT4T/yEDOZ7H5DULFNh9eMh mGwVyp9D/8D9Tr8znu9xGAhwNyR67lH1QSyy3HBnyU1gtmH0SUFveDiMrdPoMy1z4wVu DFkA== X-Forwarded-Encrypted: i=1; AJvYcCXWJVYCvBxFQmDhjrAu+WXANg07OgadtJYkAY4UKb+RLLhf8Ex/FXInlbX+1qfntWCd//QcWB1C0SUyhjA=@vger.kernel.org X-Gm-Message-State: AOJu0YzC+j8nXerKPueauCkRDRLKDEXqcrsbO5+fRH2lr6+tSUgVxBmd Ex4f74QVxCZ8o9/8PFBZSfqi+GTGqqZB1mEIb4bzm8UzZy75UG/QwrT5U8HxsIpthKCGGUknPaf K9zYD5DbrNyAT4N877FSrlBaZYcCGcBLDws0LISQSFMYxFdloKiX4tOYyaqrb8RxOOaIJUKJJ4I 6D X-Gm-Gg: ATEYQzyKrdVvWhi2m6cg7Nevjb8D2q+wnuO9x36q8tS11r3Bf+C7QV95h0W5BiqCU/z YT1JiAtGKCVcTTNTdge33Q3/Oo7Xg7DNyAx8JIt06dANR0m01T95aDyyFIMlX8Quz3oW18xyaFn Pa6TTsXGd9vFyFKNUBtjQiu6NN8mm0CmzolV9m/novBwRjh1xuoAA3sBrUcK3Qtt6nc9ysZv0GC 7BgukePm+Yx1wjTYfDJ1w1hJ/7/+qcE1b6zZKzmuBd1oIDFAYOJpUmzUUz94/3lrp3TIurTW902 hXlc73oCF9VSJeATca15qwi3+qPbyYxUh5oRuY6OcxuGYGdA6X16qc14T1L6YrectPf9A0EOza/ YvQFvlLA0r3BM/WsR2g== X-Received: by 2002:a17:902:ebc2:b0:2b0:7e4d:f390 with SMTP id d9443c01a7336-2b0827e6024mr157429855ad.41.1774354611245; Tue, 24 Mar 2026 05:16:51 -0700 (PDT) X-Received: by 2002:a17:902:ebc2:b0:2b0:7e4d:f390 with SMTP id d9443c01a7336-2b0827e6024mr157429585ad.41.1774354610733; Tue, 24 Mar 2026 05:16:50 -0700 (PDT) Received: from redhat.com ([209.132.188.88]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b083656b51sm183313715ad.54.2026.03.24.05.16.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2026 05:16:49 -0700 (PDT) Date: Tue, 24 Mar 2026 20:16:47 +0800 From: Li Wang To: Yosry Ahmed Cc: Andrew Morton , longman@redhat.com, yosryahmed@google.com, nphamcs@gmail.com, hannes@cmpxchg.org, mhocko@kernel.org, mkoutny@suse.com, muchun.song@linux.dev, tj@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v4 0/7] selftests/cgroup: improve zswap tests robustness and support large page sizes Message-ID: References: <20260322061038.156146-1-liwang@redhat.com> <20260322091851.e965d3a2f0d6af5bd985407f@linux-foundation.org> 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 Mon, Mar 23, 2026 at 05:12:27PM -0700, Yosry Ahmed wrote: > On Sun, Mar 22, 2026 at 8:23 PM Li Wang wrote: > > > > On Sun, Mar 22, 2026 at 09:18:51AM -0700, Andrew Morton wrote: > > > On Sun, 22 Mar 2026 14:10:31 +0800 Li Wang wrote: > > > > > > > This patchset aims to fix various spurious failures and improve the overall > > > > robustness of the cgroup zswap selftests. > > > > > > AI review has questions: > > > https://sashiko.dev/#/patchset/20260322061038.156146-1-liwang@redhat.com > > > > > [Sashiko comments in patch 4/7] > > > ... > > > Could we update this loop, along with the identical loops in > > > alloc_anon_noexit() and alloc_anon_50M_check_swap() shown below, to use > > > sysconf(_SC_PAGESIZE) instead? > > > > I found that Waiman submit another patch that do same thing like this > > suggestion. I'd consider to merge that one into my patch 4/7. > > > > So, let me talk to Waiman first. > > Probably fits better in your patch. > > > > The test data is generated by writing a single 'a' character per page, leaving > > > the rest zero-filled: > > > > > for (int i = 0; i < control_allocation_size; i += pagesize) > > > control_allocation[i] = 'a'; > > > > > This makes the data highly compressible. Because memory.max is set to half of > > > control_allocation_size, 512 pages are pushed into zswap. > > > > > 512 pages of mostly zeros can compress down to roughly 11 to 15 kilobytes > > > using compressors like zstd, which is well below the 65536 byte (64k) > > > zswap.max limit on a 64k page system. > > > > > Since the limit might not be reached, writeback might never trigger, > > > causing the test to falsely fail. Should the test use incompressible data > > > or a lower fixed limit? > > > > If Sashiko suggests reducing compressibility, we'd need to fill a significant > > fraction of each page with varied data, but that would work against the test: > > > > zswap would reject poorly compressing pages and send them straight to swap, > > and memory.stat:zswapped might never reach the threshold the test checks > > with cg_read_key_long(..., "zswapped") < 1. > > > > So, at most I'd keep the data highly compressible and just ensure non-zero, > > unique-per-page markers. > > Sashiko claims that 512 pages will end up consuming 11K to 15K in > zswap with this setup, do you know what the actual number is? Not very sure, I guess each 64K page contains 1 byte of 'a' and 65535 bytes of zero. A single page like that compresses down to roughly 20–30 bytes (a short literal plus a very long zero run, plus frame/header overhead). So the estimate is roughly 512 × 25 bytes ≈ 12.8 KB, which is where the "11 to 15 kilobytes" ballpark comes from. > Especially with different compressors? If it's close to 64K, this > might be a problem. Yes, good point, when I swith to use 'zstd' compressor, it doesn't work. > Maybe we can fill half of each page with increasing values? It should > still be compressible but not too compressible. I tried, this method works on Lzo algorithm but not Zstd. Anyway, I am still investigating. -- Regards, Li Wang