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 5EC1D1D416C for ; Thu, 12 Mar 2026 04:01:26 +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=1773288087; cv=none; b=VcboZqhy/ykG06SsEWqFT7KeatNR7M+c9P5bvwXcKRZud4FFIJdFDXK70qJAZAIrZTxJBby/uAPvgdB6fBjsOFM3hcvjz/86VHQXhYwCTgxfukl/vovhWk0ueCTA5jCgqOY6JHdrTk3nDGiw7o0FdVmqpb6qEKFPM9fn+EloDuQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773288087; c=relaxed/simple; bh=3dnL8OP1sS3JUUBh6YtjwfJPKK6poajEmzTKb2h768k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XLJKpHi+b6ljvGYFTWBX1IQrRcx8lWLkTciCDinpZ1B4lxRjvwqcjcVm1VDSjy5il/cNTcTroCAa/DHZhhvIDt/8w+MPI1WH5uYJlguM2G9VIZdOxSA2XLCczLUrw8pkNvtsYFmtKtldy07wATjldLwleUaz8aC0zAKIigPqY8I= 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=K9Lj9wXF; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=NpN8KdNi; 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="K9Lj9wXF"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="NpN8KdNi" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773288085; 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=3F/TPouEKOtKEG/BcHdx1b7FzxI3fZ8Dplaod3ZcPp8=; b=K9Lj9wXF2Bq7hFh7b+2i9v4ebjyfywumudAm4E3rv/3f5nHwBXyaoL+1714jFJvRgkBZGY Pb7b9+4MhQoUjz5yKiANWgm7vO3MrulI2lS/q7issZbjq/PwsIIg9Mi8MkPQilHUrWbMhL xuIB/QOUSqY+k+I7Fn/NXc9A5QA1gjY= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-674-TRezH538MDiFEIgQvnjq9Q-1; Thu, 12 Mar 2026 00:01:23 -0400 X-MC-Unique: TRezH538MDiFEIgQvnjq9Q-1 X-Mimecast-MFC-AGG-ID: TRezH538MDiFEIgQvnjq9Q_1773288083 Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-35449510446so430207a91.0 for ; Wed, 11 Mar 2026 21:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1773288083; x=1773892883; 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=3F/TPouEKOtKEG/BcHdx1b7FzxI3fZ8Dplaod3ZcPp8=; b=NpN8KdNi/k4r0h686LLSG1fgTnjETTpB7wLGBe9uAb6Vv8EzYYCL+YU89qpkqu/p2r LqA/trlVRzjTxrdg24DCQDPCicCleOO9G9Y3GLstwc4bTe1lu4TE29103lTsVkD+yJks rRgKHvaepG87OnZpgXn6Ube9X0IWoto6Q1BSP4RKm9/JwFzX/U181BSkE5IT3YrV6/XF ABISA5j62tFABi30VKirV67kBGKj7AY99E9c7fqG839jXByaFx/g1BDrLs0csyK4pn4/ KiARHjM/BYNAOEfgMG1MaGyD+UTH2YSCyybZg/fUTm1e73ZRIHhvhv5cX29dkArNQXwF hWEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773288083; x=1773892883; 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=3F/TPouEKOtKEG/BcHdx1b7FzxI3fZ8Dplaod3ZcPp8=; b=uv4Y1zil4OL+x4dPTbhS1EIiuC8xlDHu2j+yD2OmELH3kUPdOLhNoORVRnASlX5u/+ 8+/8UOdNw68H8af4SXVXENJhqOXRvB4xRTYU6DNvRADyUWludvJ+DFym9RnJoFrOGmNL xgBFbsK309iViUYf+WDnlR+Xh5kWH6dBTQH2JFEGon/xXuHcH1EUymWDoFWcaHbjyRiE z1z6x+OzUn7gryyhXH5BqiLU6UCsN51ugF7IL3qWyOEGAfec5GXZ8p7114CI/NR8EZw1 joUeIrBzPp+wTCogvwku3vQFYksee4aKjNrtsruXCEErH3XLkh+ZDxgR1S9Mh9qQTth9 3KTw== X-Forwarded-Encrypted: i=1; AJvYcCWGk23uKLqpCfl7U9x0bOkZmm28drl6kWp3SroNWMxivFNIzw/gKEhmTtAuUE2Ror8j/njC1SRVJHe5HKk=@vger.kernel.org X-Gm-Message-State: AOJu0YwTzf3w0UUezD7Qd1FRRb4ygxZdriYlgeM9YHcqG1oX7UJyhx+J DdRw/PPA/KGr3S7eyl5xykOBzRwtBWdklqAU7btlfS836wjY0vg86eFeqAq23XDAG/MAi2kq/e5 WJCShbQfxnyGXvfu6c8psU+xihqaA69obUBs/0tTDDKgN9+zmG0FE3NH8Yp/+YTOrZA== X-Gm-Gg: ATEYQzy9xlCu7S4mNXjA4PNLWQsnqOSPyGsKJf6dtStMZPmORZO+Kk5/oCdFJ/Zwbt6 X7cX9kDJUokD+ZeQbRPZrYtnE1Bq4MzY88KK0sxHzSOdzRNrOFsYOCWEQbTnMUom446n5jQ7hme 4peXw/8E9oGhVXipCFNCQUJasqt/mCxk03wRpq+0XX3J5qkFE1TIg7U+lQIYcA+SV7dOtVHkKFu LLY5p4QdvAiUDRBKNNBqzT5z7vqICgIfMa+/Lq0l61RZj574IazkOj1oev2qQS7msmJyYzGxI67 /PpH44zGhy2UU/x/PR1HJ+BQlTQeq9t7lC0lxPY5x12oHE/BOqF+1VmS1p8gKAiOXFy9usEqF0M BAVFmiQUYXiTD/Ljvlg== X-Received: by 2002:a17:90b:4a8d:b0:359:8256:19f9 with SMTP id 98e67ed59e1d1-35a012dd184mr4558804a91.15.1773288082728; Wed, 11 Mar 2026 21:01:22 -0700 (PDT) X-Received: by 2002:a17:90b:4a8d:b0:359:8256:19f9 with SMTP id 98e67ed59e1d1-35a012dd184mr4558769a91.15.1773288082296; Wed, 11 Mar 2026 21:01:22 -0700 (PDT) Received: from redhat.com ([209.132.188.88]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-359f05ee4a7sm7779151a91.4.2026.03.11.21.01.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2026 21:01:21 -0700 (PDT) Date: Thu, 12 Mar 2026 12:01:19 +0800 From: Li Wang To: Yosry Ahmed Cc: linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, Johannes Weiner , Michal Hocko , Michal =?utf-8?Q?Koutn=C3=BD?= , Muchun Song , Nhat Pham , Tejun Heo , Roman Gushchin , Shakeel Butt Subject: Re: [PATCH 2/5] selftests/cgroup: avoid OOM in test_swapin_nozswap Message-ID: References: <20260311110523.26624-1-liwang@redhat.com> <20260311110523.26624-2-liwang@redhat.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, Mar 11, 2026 at 11:50:05AM -0700, Yosry Ahmed wrote: > On Wed, Mar 11, 2026 at 4:05 AM Li Wang wrote: > > > > test_swapin_nozswap can hit OOM before reaching its assertions on some > > setups. The test currently sets memory.max=8M and then allocates/reads > > 32M with memory.zswap.max=0, which may over-constrain reclaim and kill > > the workload process. > > > > Raise memory.max to 24M so the workload can make forward progress, and > > lower the swap_peak expectation from 24M to 8M to keep the check robust > > across environments. > > > > The test intent is unchanged: verify that swapping happens while zswap > > remains unused when memory.zswap.max=0. > > > > === Error Logs === > > > > # ./test_zswap > > TAP version 13 > > 1..7 > > ok 1 test_zswap_usage > > not ok 2 test_swapin_nozswap > > ... > > > > # dmesg > > [271641.879153] test_zswap invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0 > > [271641.879168] CPU: 1 UID: 0 PID: 177372 Comm: test_zswap Kdump: loaded Not tainted 6.12.0-211.el10.ppc64le #1 VOLUNTARY > > [271641.879171] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW940.02 (UL940_041) hv:phyp pSeries > > [271641.879173] Call Trace: > > [271641.879174] [c00000037540f730] [c00000000127ec44] dump_stack_lvl+0x88/0xc4 (unreliable) > > [271641.879184] [c00000037540f760] [c0000000005cc594] dump_header+0x5c/0x1e4 > > [271641.879188] [c00000037540f7e0] [c0000000005cb464] oom_kill_process+0x324/0x3b0 > > [271641.879192] [c00000037540f860] [c0000000005cbe48] out_of_memory+0x118/0x420 > > [271641.879196] [c00000037540f8f0] [c00000000070d8ec] mem_cgroup_out_of_memory+0x18c/0x1b0 > > [271641.879200] [c00000037540f990] [c000000000713888] try_charge_memcg+0x598/0x890 > > [271641.879204] [c00000037540fa70] [c000000000713dbc] charge_memcg+0x5c/0x110 > > [271641.879207] [c00000037540faa0] [c0000000007159f8] __mem_cgroup_charge+0x48/0x120 > > [271641.879211] [c00000037540fae0] [c000000000641914] alloc_anon_folio+0x2b4/0x5a0 > > [271641.879215] [c00000037540fb60] [c000000000641d58] do_anonymous_page+0x158/0x6b0 > > [271641.879218] [c00000037540fbd0] [c000000000642f8c] __handle_mm_fault+0x4bc/0x910 > > [271641.879221] [c00000037540fcf0] [c000000000643500] handle_mm_fault+0x120/0x3c0 > > [271641.879224] [c00000037540fd40] [c00000000014bba0] ___do_page_fault+0x1c0/0x980 > > [271641.879228] [c00000037540fdf0] [c00000000014c44c] hash__do_page_fault+0x2c/0xc0 > > [271641.879232] [c00000037540fe20] [c0000000001565d8] do_hash_fault+0x128/0x1d0 > > [271641.879236] [c00000037540fe50] [c000000000008be0] data_access_common_virt+0x210/0x220 > > [271641.879548] Tasks state (memory values in pages): > > ... > > [271641.879550] [ pid ] uid tgid total_vm rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name > > [271641.879555] [ 177372] 0 177372 571 0 0 0 0 51200 96 0 test_zswap > > [271641.879562] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=/,mems_allowed=0,oom_memcg=/no_zswap_test,task_memcg=/no_zswap_test,task=test_zswap,pid=177372,uid=0 > > [271641.879578] Memory cgroup out of memory: Killed process 177372 (test_zswap) total-vm:36544kB, anon-rss:0kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:50kB oom_score_adj:0 > > Why are we getting an OOM kill when there's a swap device? Is the > device slow / not keeping up with reclaim pace? This is a good question. The OOM is triggered very likely because memcg reclaim can't make forward progress fast enough within the retry budget of try_charge_memcg. Looking at the OOM info, the system has 64K pages, so memory.max=8M gives only 128 pages. At OOM time, RSS is 0 and swapents is only 96. Swap space itself isn't full, the charge path simply gave up trying to reclaim. The core issue, I guess, is that with memory.zswap.max=0, every page reclaimed must go through the real block device. The charge path works like this: a page fault fires, charge_memcg tries to charge 64K to the cgroup, the cgroup is at its limit, so try_charge_memcg attempts direct reclaim to free space. If the swap device can't drain pages fast enough, the reclaim attempts within the retry loop fail to bring usage below memory.max, and the kernel invokes OOM, even though swap space is technically available. Raising memory.max to 24M gives reclaim a much larger pool to work with, so it can absorb I/O latency without exhausting its retry budget. -- Regards, Li Wang