From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 89D69EC1126 for ; Mon, 23 Feb 2026 20:30:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD4A06B0005; Mon, 23 Feb 2026 15:30:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B8C2A6B0089; Mon, 23 Feb 2026 15:30:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A98516B008A; Mon, 23 Feb 2026 15:30:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 967AC6B0005 for ; Mon, 23 Feb 2026 15:30:27 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 440A714031E for ; Mon, 23 Feb 2026 20:30:27 +0000 (UTC) X-FDA: 84476864094.20.C245AFE Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf17.hostedemail.com (Postfix) with ESMTP id E9A0C40011 for ; Mon, 23 Feb 2026 20:30:24 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=QAV9pkvJ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=guiWv8G0; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=2IaIncf1; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="bRh/AN1Q"; dmarc=none; spf=pass (imf17.hostedemail.com: domain of dsterba@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=dsterba@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1771878625; a=rsa-sha256; cv=none; b=MP3a/eNCrNy5FVnSz+62ESQ2YoYYB6DbTzYC0caQDkyJrS0XPMwaFsCqvhJw+wxhfWC4TI YlBQaO3hGWdG1W7OkZ5uRjDMoUXFCxLC/mMe4L4VrxCKHCbPl31sKVWjHf3hyf6eOfG3Vj zT5VUhJY7SMzbgFbg6LX1J3xjLjM8ZU= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=QAV9pkvJ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=guiWv8G0; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=2IaIncf1; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="bRh/AN1Q"; dmarc=none; spf=pass (imf17.hostedemail.com: domain of dsterba@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=dsterba@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1771878625; h=from:from:sender:reply-to: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SC/IaqixQPdjviB9CgBRZcLmSGCPDAzf3cSg7lkDBoM=; b=EfN8SAf+P+swIUmiOp4LsSmH8PFwr31hrM4WodXAP7Hr5fLliwmi1CJVKEs6l1kGBvny5W nkFqQxM/gEX8AMXIWALUqOZALMsSFOiDhW6T8hJND/RYBWW2suc+DYH3zis9rZIlN9BDSG sNNAUShDCX/OfBhAd1md84H1YWKmecE= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id F17295BCE9; Mon, 23 Feb 2026 20:30:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1771878623; h=from:from:reply-to:reply-to: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=SC/IaqixQPdjviB9CgBRZcLmSGCPDAzf3cSg7lkDBoM=; b=QAV9pkvJql9fL7yW44dlolX4+jS1z/3WsTgUbesIZr8oNqj4+BMS7VN6b1Tnmkh71X1hc9 U2/7rYFytw7kRo8L0X/HCzua07CsWYdICkpIwopRgjrO8DDIE6M6qpTY5tC1kCNBdW9FoU k9E3dkGCrd6ZbOECF8PLvhyKdTtcIXk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1771878623; h=from:from:reply-to:reply-to: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=SC/IaqixQPdjviB9CgBRZcLmSGCPDAzf3cSg7lkDBoM=; b=guiWv8G0AUeUlj7FQ8EXfhJhO6E56kb35pTggmzdd5ZmPzdZ+tsVyTSBJug+JbQVIo/SC1 ZcNnJzrN3OEh+zAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1771878622; h=from:from:reply-to:reply-to: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=SC/IaqixQPdjviB9CgBRZcLmSGCPDAzf3cSg7lkDBoM=; b=2IaIncf1pj3NpuLUVH2W6JCsQ+uRZ2aTJE7JwSVPzb2J+oYpWbE4T1+NzViMLkoZNqbwkC Za8PwwD9YqUs+DO3Op2hVzLkasW/+WoJviko/ei9FBBf+TYFTjsqYJ7BDVLWOm/3EwpW/s dD8OvByWrzrZAOj39xxKiWqTkZDeIaE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1771878622; h=from:from:reply-to:reply-to: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=SC/IaqixQPdjviB9CgBRZcLmSGCPDAzf3cSg7lkDBoM=; b=bRh/AN1Q6THpJGY3Yl0Hyoxeq/og2JhaiqD2yt2nRhyMxeNlVq8gadSOV07NeGzJDVpZu+ LHD4lYAuRHiZsrAA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id BA8A23EA68; Mon, 23 Feb 2026 20:30:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id HIJfLd64nGmybQAAD6G6ig (envelope-from ); Mon, 23 Feb 2026 20:30:22 +0000 Date: Mon, 23 Feb 2026 21:30:21 +0100 From: David Sterba To: Harry Yoo Cc: Chris Bainbridge , vbabka@suse.cz, surenb@google.com, hao.li@linux.dev, leitao@debian.org, Liam.Howlett@oracle.com, zhao1.liu@intel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-btrfs@vger.kernel.org, regressions@lists.linux.dev Subject: Re: [REGRESSION] kswapd0: page allocation failure (bisected to "slab: add sheaves to most caches") Message-ID: <20260223203021.GP26902@twin.jikos.cz> Reply-To: dsterba@suse.cz References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E9A0C40011 X-Stat-Signature: wuwuowd6zaniymchzo7b87rzqa5y5dbh X-HE-Tag: 1771878624-741205 X-HE-Meta: U2FsdGVkX19p9yiD/eLBGF0dQjwV3Xy5SOhsx33o4VwKgnCvqTv2KI3dhkgmjKXvkK8XZjeBLRo8C/6bGGxVlfRKO1sBQ9Hd4quGNBNSPFzu8p2gxFhVCrpi3XcBEWIBBplUt/l/o8OpJqHXMf6DCsgmlOULQoLsb+aIXAJ8J+BSBdnzzo16YRCNaF8Y3Q9Eza7orK1XO3EwtNl0LxFkq9q2zhFmY0SfO4RFgTHFLcs8ce0I+OnURrQqqB2qOuW/VOBs/c7DHl0dhimmlhWf7we4HVs2S+arPYcMiooHrKCWbwjXFNjHBfphCTNbE0YN9765eTWhK8YSmhOAULXdsv0RSuHdf0kEcA8OLaS1cdkPEn7JcH81tIhCDOwXU7U3TeXCjJDTE/maAm6pJURi7TiAVP61xOXDqQlop2nJzFRcvfzAj0rC2wnfUoWYtEnLeYNa6PdfQ6eMaKDwEvr7fZa1pK1ePtwFU6PxgQOMCFX5aqy4vfQUMOivcxD/mde676ZrIqLzk8XdtqO+51E1+dsbSFX8EyqN0GN6hZZ4Rs2og88gHwnv5dDoBtCtUQ0Hdw2mdZTJQAH+f40N/TSHxHTvMqEv2GRBP8uEZuG1ydaBZv1ZzcnPROJz0oTe8mHZezqCVmxQnd9wB5MwWWF12GmHww/+kO+x7PzdmS/AGcptIX6S25nsnKiROUZQBtkexw23uI9VxfbMfjGLAaY+FqVxlZg7idXY9QESfsFs1joOEBQ7UDzY3JnB+pmGOZ/4QZSwyiUkPLMGH9+jP2lbp9l65Ybj9dZYnjHnV2vuTziI8YZZipJcCu8Qo4SoxoRiI7/zvP65oOZn+0pCCLVJskIlUELnt5fAszTeiKuWNlmYt+UzxkzgaBPboD8XVf2DBBBs+DzsscxNCoKSe2fbSz9yqaUL1BMuO8lqtsge3TFMmfJjXR+wqRqzePbToxOL5aIPggBoKb2FOr3om3E zG8xAUvB n1jOw4WPbBQlolnuUAwe7BausCSCvGD/6DgspJnj4PGmyPUuoaAeMalvoviHzPcDwXISCXGEzz5VG1pAJz9ilJuxE9E/+vJRLiiBO X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Feb 23, 2026 at 08:59:30PM +0900, Harry Yoo wrote: > On Mon, Feb 23, 2026 at 11:12:47AM +0000, Chris Bainbridge wrote: > > On Mon, Feb 23, 2026 at 05:41:17PM +0900, Harry Yoo wrote: > > > On Sun, Feb 22, 2026 at 09:36:58PM +0000, Chris Bainbridge wrote: > > > > Hi, > > > > > > > > The latest mainline kernel (v6.19-11831-ga95f71ad3e2e) has page > > > > allocation failures when doing things like compiling a kernel. I can > > > > also reproduce this with a stress test like > > > > `stress-ng --vm 2 --vm-bytes 110% --verify -v` > > > > > > Hi, thanks for the report! > > > > > > > [ 104.032925] kswapd0: page allocation failure: order:0, mode:0xc0c40(GFP_NOFS|__GFP_COMP|__GFP_NOMEMALLOC), nodemask=(null),cpuset=/,mems_allowed=0 > > > > [ 104.033307] CPU: 4 UID: 0 PID: 156 Comm: kswapd0 Not tainted 6.19.0-rc5-00027-g40fd0acc45d0 #435 PREEMPT(voluntary) > > > > [ 104.033312] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024 > > > > [ 104.033314] Call Trace: > > > > [ 104.033316] > > > > [ 104.033319] dump_stack_lvl+0x6a/0x90 > > > > [ 104.033328] warn_alloc.cold+0x95/0x1af > > > > [ 104.033334] ? zone_watermark_ok+0x80/0x80 > > > > [ 104.033350] __alloc_frozen_pages_noprof+0xec3/0x2470 > > > > [ 104.033353] ? __lock_acquire+0x489/0x2600 > > > > [ 104.033359] ? stack_access_ok+0x1c0/0x1c0 > > > > [ 104.033367] ? warn_alloc+0x1d0/0x1d0 > > > > [ 104.033371] ? __lock_acquire+0x489/0x2600 > > > > [ 104.033375] ? _raw_spin_unlock_irqrestore+0x48/0x60 > > > > [ 104.033379] ? _raw_spin_unlock_irqrestore+0x48/0x60 > > > > [ 104.033382] ? lockdep_hardirqs_on+0x78/0x100 > > > > [ 104.033394] allocate_slab+0x2b7/0x510 > > > > [ 104.033399] refill_objects+0x25d/0x380 > > > > [ 104.033407] __pcs_replace_empty_main+0x193/0x5f0 > > > > [ 104.033412] kmem_cache_alloc_noprof+0x5b6/0x6f0 > > > > [ 104.033415] ? alloc_extent_state+0x1b/0x210 [btrfs] > > > > [ 104.033479] alloc_extent_state+0x1b/0x210 [btrfs] > > > > [ 104.033527] btrfs_clear_extent_bit_changeset+0x2be/0x9c0 [btrfs] > > > > > > Hmm while bisect points out the first bad commit is > > > commit e47c897a2949 ("slab: add sheaves to most caches"), > > > > > > I think the caller is supposed to specify __GFP_NOWARN if it doesn't > > > care about allocation failure? > > > > > > btrfs_clear_extent_bit_changeset() says: > > > > if (!prealloc) { > > > > /* > > > > * Don't care for allocation failure here because we might end > > > > * up not needing the pre-allocated extent state at all, which > > > > * is the case if we only have in the tree extent states that > > > > * cover our input range and don't cover too any other range. > > > > * If we end up needing a new extent state we allocate it later. > > > > */ > > > > prealloc = alloc_extent_state(mask); > > > > } > > > > > > Oh wait, I see what's going on. bisection pointed out the commit > > > because slab tries to refill sheaves with __GFP_NOMEMALLOC (and then > > > falls back to slowpath if it fails). > > > > > > Since failing to refill sheaves doesn't mean the allocation will fail, > > > it should specify __GFP_NOWARN with __GFP_NOMEMALLOC as long as there's > > > fallback method. > > > > > > But for __prefill_sheaf_pfmemalloc(), it should specify __GPF_NOWARN on > > > the first attempt only when gfp_pfmemalloc_allowed() returns true. > > > > Is this fix sufficient to do the right thing? I tested it, and it does > > appear to prevent logging of the allocation failures for my test case. > > I think we should do both both 1) setting __GFP_NOWARN from btrfs side > and 2) making slab try to refill sheaves with __GFP_NOWARN when > there's a fallback path. > > I'm writing a fix for 2) and I'll send it soon. > > > diff --git a/fs/btrfs/extent-io-tree.c b/fs/btrfs/extent-io-tree.c > > index d0dd50f7d279..d2e1083848e8 100644 > > --- a/fs/btrfs/extent-io-tree.c > > +++ b/fs/btrfs/extent-io-tree.c > > @@ -641,7 +641,7 @@ int btrfs_clear_extent_bit_changeset(struct extent_io_tree *tree, u64 start, u64 > > * cover our input range and don't cover too any other range. > > * If we end up needing a new extent state we allocate it later. > > */ > > - prealloc = alloc_extent_state(mask); > > + prealloc = alloc_extent_state(mask | __GFP_NOWARN); > > This seems to be a right thing to do to me, but as I'm not familiar > with btrfs, I'll let btrfs folks leave comment on it :) I agree the flag should be added, as the comment explains allocation failures are not fatal at this place. There's another call to the alloc_extent_state() with GFP_ATOMIC so we cannot simply sink NOWARN there.