From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) (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 6615118A92F for ; Wed, 1 Apr 2026 07:24:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775028282; cv=none; b=mfcQYh/RgSptbtMWOiRxMPLQ3lEb9FQiCgyB3x7d30ni5xWMV+/2P5U6g3gOIfUh3WBQTMft/Oi/0rRXRC/wx6mfFjPlRZ+EF6Uobbjkd829149x1u+53o19JNAGUjJU3slyyBdcBBc2/oHnE020lzzaYZ3+czJWe6QyPGj6Gas= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775028282; c=relaxed/simple; bh=jBUz8w2UE+AbwbR7JZXLDoWhwvffeOU6nnCILyxmmkc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=JSKHyXdM/mVe9vEXiiwY+iyEdL26bt1Gm3wtt2vqeYXab9kJi0D0Xs19ndKLSRIDtvPMJ7GGZ34UceCdBS0vtSSUUsOuHArQJQPfBLdyaBMa4KHZpE4U+QiYJnRYSVYRTWfHIWea6js0pxrdAnS02EGH8FDxvKOF/xVpIpzl9Ls= 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=nOp9qoi3; arc=none smtp.client-ip=91.218.175.177 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="nOp9qoi3" Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1775028278; 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=jBUz8w2UE+AbwbR7JZXLDoWhwvffeOU6nnCILyxmmkc=; b=nOp9qoi3K2/azDm9AMPdcYjpHKIIft6n5Ke/8NJLYkWH0ZPwI73cpUqF37jSw2FdOscju0 iVUuSr5IoJMMCijdyebScM7xG/uyqWVf5G8s1WW10WI1QqchBGjYmb82KoCQMRclCIWefy WGUrzV6w4EDIz9mQ3MOnMUVQl0RVOQ0= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\)) Subject: Re: [PATCH] mm/sparse: fix BUILD_BUG_ON check for section map alignment X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <9fddd112-e304-4ce1-b3f0-a4b133fcb281@kernel.org> Date: Wed, 1 Apr 2026 15:23:59 +0800 Cc: Muchun Song , Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Petr Tesarik , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260331113023.2068075-1-songmuchun@bytedance.com> <32789381-f860-4b60-a1e1-4c97f6ed08b1@kernel.org> <7C90E910-D229-4F60-A62D-E893A89D58F2@linux.dev> <1742503A-F912-4AB6-AAF6-6CDB06829024@linux.dev> <9fddd112-e304-4ce1-b3f0-a4b133fcb281@kernel.org> To: "David Hildenbrand (Arm)" X-Migadu-Flow: FLOW_OUT > On Apr 1, 2026, at 15:08, David Hildenbrand (Arm) = wrote: >=20 > On 4/1/26 06:01, Muchun Song wrote: >>=20 >>=20 >>> On Apr 1, 2026, at 10:57, Muchun Song wrote: >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> If that would trigger, wouldn't the memmap of a memory section be >>>> smaller than a single page? >>>=20 >>> I don't think a memory section can be smaller than a page, because >>> PFN_SECTION_SHIFT is defined as follows: >>>=20 >>> #define PFN_SECTION_SHIFT (SECTION_SIZE_BITS - PAGE_SHIFT) >>>=20 >>> Therefore, PFN_SECTION_SHIFT must be greater than PAGE_SHIFT. On = powerpc, >>> PFN_SECTION_SHIFT is 6, PAGE_SHIFT is 18 (the worst combination). >>>=20 >>> Sorry, but I didn't understand what your concern is. Could you = elaborate >>> a bit more? >>=20 >> Sorry, I misread it earlier =E2=80=94 I thought it was about the = memory >> section size, but it's actually about the memmap size. Let me respond >> again to your question. On the powerpc architecture, when = PFN_SECTION_SHIFT >> is 6 and PAGE_SHIFT is 18, it does seem that the memmap of a memory >> section would be smaller than a single page. >=20 > Right, and I am saying we don't care about that and do not support it. >=20 > For example, most vmemmap code I am aware of relies on a single = section > covering full pages. >=20 > So I don't think this patch here adds any value, except faking that we > might be supporting something we don't? Got it. My original motivation was simply that when I read this part of the = code, the comment felt a bit off to me, so I just fixed it casually. But if it ends up creating the impression that "we might be supporting something we don't," as you said, then I'm fine with dropping this patch. Thanks. >=20 > --=20 > Cheers, >=20 > David