From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BYAPR05CU005.outbound.protection.outlook.com (mail-westusazon11010066.outbound.protection.outlook.com [52.101.85.66]) (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 8AD323A7F69 for ; Thu, 9 Apr 2026 09:28:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.85.66 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775726929; cv=fail; b=jKMhBSGDrE+1tv4dpQ8d0N+Q3US7GMbcHlOVEeIuApLrwWr3zWKM6RyOECpsbR2+n1njaysc5fNMBOrg8u/U1BWLBCgr3X6g8qWe8r4yTJwZhsQZ8XwbZH1soTk696q4PfPIEwSzs6DeO1/WMz9eCxiwegf8Vn+Gg0IMaCdxGos= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775726929; c=relaxed/simple; bh=I5nI6GuRUojeVdjF3RyVM2e2coC8FCnpZZrmAWsenMM=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=a4ZoIvMl71wDaSGCwpG+3eNcAz1fgTcJOA8k3fi6gPXHbAgKmUQEdAUWAOum+Nz9aoIynFM05FJFCUOQj6up2QwEjJ0p6ghv47xuLPUJovYW6cAsk1DFKp+aVbKudWZX3K3c2DBjj1yVTfc27maTVkR3qJrbO1rBMHLGOBgVXSQ= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=K0g1CEXh; arc=fail smtp.client-ip=52.101.85.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="K0g1CEXh" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=d2rhxAENnfxnVbIVyk8jUR+176qqLtQyKGGGSu8M70Fk/xsYCYPgJpCLb4Y7RQVeAaz2a3mOP/I4sVVe7v2+UpXxTg7ToJh22B2L48c48mGhNbwAgXCP855BbjgnKhOmHNr2fqFzZQVliV1WXZ5gTQwoYZDeo0jVZ5kM96cxKFgk+Ef/tDK+mr0jfTW6u+3aUcGTW3Rg1CXD4RuhaBJYyyzkDwpv7ZK7g3yhxj5RxyE6CtWSE3MmVB+dYhtTn/KsUiThxKfp29BzMzqzx7aOfB+8e4wXbFhUCC3RLS0QVtaBQOmIlVTiiaMG/SWH3s0uL9uXnEmn2LqPurnAZW1arQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gkxUnfFIQtsRR0zCsYDDfR8OXXTvOaGf9mFUA7vPf1w=; b=F2dSTZoE6t9RyKPCh4rhjoXY5sC+dBnCaTwbqdQSIknhC3/F+zkMYb+Oti8YM5kzWncLot0cJOcHGghxQSsZRXFxNXBNpNax0udg6lgtgnPqqx4jsavHrK9JJRejZcvGqCUeg58ToUg1Fxoauq5oXgmGxksEa6hah65R6/tHL7knCLHzD6bi3dG5fv3XZJw0NFWeqGIbVVBaoDIQz3UsUiTLkxTxNIopgMTpbtO38Qm3InfzZtQ3iiacG40OQV/ULdox4pz73jrginFT6P4wXcVZ5AwFucoqFrqcYMkByFT0hbiuCOZK5Gp+1nl5EQK5HD/2DD+a1WdfvXKIpiXesQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gkxUnfFIQtsRR0zCsYDDfR8OXXTvOaGf9mFUA7vPf1w=; b=K0g1CEXhzlytc8kNU9+LTgNEXLv5N3UG1wZFLXs8xdchbTsvjYenPsbcbPKJ5eGi77vixvufHFI+OKB65yaSPH+GnEy0DU/2/Hqy82TqsLlSlSnaRXzWhv7AMpWAMJxPjIDrOIiLS5cZZqxBZ1aDip+yNnq6KV3U4tv/BZXHgtk= Received: from CH0PR03CA0100.namprd03.prod.outlook.com (2603:10b6:610:cd::15) by IA1PR12MB6652.namprd12.prod.outlook.com (2603:10b6:208:38a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.20; Thu, 9 Apr 2026 09:28:40 +0000 Received: from CH2PEPF0000013F.namprd02.prod.outlook.com (2603:10b6:610:cd:cafe::ba) by CH0PR03CA0100.outlook.office365.com (2603:10b6:610:cd::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9769.41 via Frontend Transport; Thu, 9 Apr 2026 09:28:40 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Received: from satlexmb08.amd.com (165.204.84.17) by CH2PEPF0000013F.mail.protection.outlook.com (10.167.244.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.17 via Frontend Transport; Thu, 9 Apr 2026 09:28:40 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 9 Apr 2026 04:28:33 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 9 Apr 2026 04:28:33 -0500 Received: from [10.136.43.140] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 9 Apr 2026 04:28:30 -0500 Message-ID: <5c01d4ba-4453-47ac-9904-6ad6dbd69c2c@amd.com> Date: Thu, 9 Apr 2026 14:58:29 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/page_alloc: use batch page clearing in kernel_init_pages() To: "David Hildenbrand (Arm)" , Andrew Morton CC: "Vlastimil Babka (SUSE)" , , , , , , , , , , , , References: <20260408092441.435133-1-hsalunke@amd.com> <22b6ff3c-9d41-4eb0-9beb-cb92f3ada89f@kernel.org> <4e8c218b-ac5e-4674-9e1e-acf750f0a5c8@amd.com> <20260408083229.45d1a083f17484d3b2678855@linux-foundation.org> <4dd26573-85cc-446a-b2b7-2aeab8aa2417@kernel.org> Content-Language: en-US From: "Salunke, Hrushikesh" In-Reply-To: <4dd26573-85cc-446a-b2b7-2aeab8aa2417@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF0000013F:EE_|IA1PR12MB6652:EE_ X-MS-Office365-Filtering-Correlation-Id: 44616498-bf1b-41da-9393-08de961a62d9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|82310400026|7416014|1800799024|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: jGvbb/TI4zweUUKG6dH/A950aJewbe0PJs7I/LwJTIpDX/a8dJwJjhum2/3+toVR07wuPefV6awlau/HZx4hkC4hjfIMk4TMWi1LH9t+0wFFq5cuIfdn03uiy9whoMjsMh7A1LuBNpc2AO6eoDYa6MY3aCizkcKwKSsL9ElkiEFlU78TXhorhCxX7vPfHDyaP0AnpZjjwA9J4c0bSdeSr5lHpvUOAzHpwynJ9QHD2j+UaHEhroTmOCBL18P3lVzuzY7lXRqrJ7WCM10h53ABzgF9E5MrGIvI14dnfXEpzQJvcGhya0QKqEGu5XGQt0BaXtvrWQVFdddp4Auie5ArpBM0+vAMPEAmrJnotIQzmpgTvG3XeuOIhrQ2ddITriRapJpEwBHP7vf0flV/jrGSItFZnQf6j5+49E6PaeswmH7gxIgO+BRo6QeOx+NgQfJ8OMveFppfBmxIZvxHx6ML5DcZ48amjQUohTUJ1LOU3Azb4l6/DhZvxUjhrRIU9E1iEQfVKNV18+JF1nVS/kLiObZS9OHHrw6B+I/Y0w+WrGD2eyxjdyTla74QlhBC0231Qnx9TNmiw1NZk3ucZXIASxM37C2NW6bLCCs87AHiyFzvYR6zabHxYsKHKJPScmRJoiGS4SzDKHDEAF+V3VEMKYHPKScl1pFMaOsOWNA7DFjL7UVYjswpTxMJFuPHP11yy3Hxnti36xMhyxuebistc6LS11rJb0N5kMZsmJLLiHbrD0np/N36ndwxWPKOqrybUe3i+tjHK+WNKWEDAIssWg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700016)(82310400026)(7416014)(1800799024)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: C1MiqjSXV1vSTMVqh+TczXCXImxoQvebCPPKF7XUXsVR76Iy93LO3mL9UB51eovA416UfqCQl2cE5yzqwU5Lvr6+SPtLHomdR5FWMqYSkthhuMlPZgvwrwvBlwHY04RALDiHHYuUrJ8Agfa6kZpLqZ0bRvSSWFS03FgWgacgkAgS4qgUsKYHdNU6q8lPWeBVhRtf4ZzRORL4vIOM6jWGoTs3l+DkXuMozARg1D+RA0F7gqq8zwBmVvxij5HlaqXe0rZKCRbsw+L49hRfQRfVHgQfHDnBv11t5lKKyNzVEeDBITk8++uEZiisYsY1+LzzpHpCrVp+9B1hx0Ar3BzLPgRqEXD3obBM2vZuizi6KGU7TLLegUQo1xHjECS9FVPQc0sbE2dtrBAiMRxYJLnzW8EIVFOceApX7p5RNUqAA6m6uWYQaxH0Bkfoiq+2H0Vr X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2026 09:28:40.4392 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 44616498-bf1b-41da-9393-08de961a62d9 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF0000013F.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6652 On 09-04-2026 14:30, David Hildenbrand (Arm) wrote: > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > On 4/9/26 10:55, Salunke, Hrushikesh wrote: >> On 08-04-2026 21:02, Andrew Morton wrote: >> >>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. >>> >>> >>> On Wed, 8 Apr 2026 16:14:03 +0530 "Salunke, Hrushikesh" wrote: >>> >>>> kernel_init_pages() runs inside the allocator (post_alloc_hook and >>>> __free_pages_prepare), so it inherits whatever context the caller is in. >>>> Testing with CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_PROVE_LOCKING=y, I >>>> hit this during exit_group() -> exit_mmap() -> __zap_vma_range, where a >>>> page allocation happens while the PTE lock and RCU read lock are held, >>>> making the cond_resched() in the clearing loop illegal: >>>> >>>> [ 1997.353228] BUG: sleeping function called from invalid context at mm/page_alloc.c:1235 >>>> [ 1997.353433] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 19725, name: bash >>>> [ 1997.353572] preempt_count: 1, expected: 0 >>>> [ 1997.353706] RCU nest depth: 1, expected: 0 >>>> [ 1997.353837] 3 locks held by bash/19725: >>>> [ 1997.353839] #0: ff38cd415971e540 (&mm->mmap_lock){++++}-{4:4}, at: exit_mmap+0x6e/0x430 >>>> [ 1997.353850] #1: ffffffffb03d6f60 (rcu_read_lock){....}-{1:3}, at: __pte_offset_map+0x2c/0x220 >>>> [ 1997.353855] #2: ff38cd410deb4618 (ptlock_ptr(ptdesc)#2){+.+.}-{3:3}, at: pte_offset_map_lock+0x92/0x170 >>>> [ 1997.353868] Call Trace: >>>> [ 1997.353870] >>>> [ 1997.353873] dump_stack_lvl+0x91/0xb0 >>>> [ 1997.353877] __might_resched+0x15f/0x290 >>>> [ 1997.353882] kernel_init_pages+0x4b/0xa0 >>>> [ 1997.353886] get_page_from_freelist+0x406/0x1e60 >>>> [ 1997.353895] __alloc_frozen_pages_noprof+0x1d8/0x1730 >>>> [ 1997.353912] alloc_pages_mpol+0xa4/0x190 >>>> [ 1997.353917] alloc_pages_noprof+0x59/0xd0 >>>> [ 1997.353919] get_free_pages_noprof+0x11/0x40 >>>> [ 1997.353921] __tlb_remove_folio_pages_size.isra.0+0x7f/0xe0 >>>> [ 1997.353923] __zap_vma_range+0x1bbd/0x1f40 >>>> [ 1997.353931] unmap_vmas+0xd9/0x1d0 >>>> [ 1997.353934] exit_mmap+0x10a/0x430 >>>> [ 1997.353943] __mmput+0x3d/0x130 >>>> [ 1997.353947] do_exit+0x2a7/0xae0 >>> tlb_next_batch() is (fortunately) using GFP_NOWAIT. Perhaps you can >>> alter your patch to not call the cond_resched() if caller is attempting >>> an atomic allocation. >> >> Thanks Vlastimil, David, Andrew, and Raghu for the reviews. >> >> After looking into this more, I think adding cond_resched() here was >> overkill. I agree that dropping cond_resched() and >> PROCESS_PAGES_NON_PREEMPT_BATCH entirely and just calling clear_pages() >> is the right approach. There's no case where cond_resched() in >> kernel_init_pages() is both necessary and safe: >> >> - It's unsafe in atomic context, as the BUG shows (tlb_next_batch() >> allocates under PTE lock + RCU read lock via GFP_NOWAIT). >> - It's unnecessary for common allocations (order-0, mTHP, 2MB) which >> clear in well under 1ms. >> - For 1 GiB hugepages, kernel_init_pages() only runs during the >> initial admin-triggered allocation. When processes later fault on >> those pages, clearing goes through folio_zero_user() -> >> clear_contig_highpages(), not kernel_init_pages(). >> >> So rather than guarding cond_resched() with GFP flags (as Andrew >> suggested), I'll remove it entirely in v2 to keep things simple and >> same scheduling characteristics as the original code, just with the >> batch clearing performance benefit. >> >> Regarding the 512 MiB arm64 case that David mentioned the stall from >> clearing that without cond_resched() under PREEMPT_NONE is acceptable, >> or should it be handled differently? Thanks David. > I mean, it would already happen today, because there is no > cond_resched(). So nothing to worry about I guess. Right makes sense. > >> I can introduce clear_highpages_kasan_tagged() / clear_highpages() >> helpers, or keep v2 minimal with the logic inline in >> kernel_init_pages(). Any preference? > I'd prefer not sprinkling IS_ENABLED(CONFIG_HIGHMEM) around and simply > calling a clear_highpages_kasan_tagged() from kernel_init_pages(). > Sounds good. I'll add a clear_highpages_kasan_tagged() helper in highmem.h and have kernel_init_pages() call it directly. Will send v2 shortly. Regards, Hrushikesh