From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 C662B40DFC1 for ; Tue, 16 Jun 2026 07:57:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781596627; cv=none; b=B72XHTT5Va11+VHyHuZGhuHVnSC9adG18894zdQVUN8NFBiejjUhqPE7dqdKycaga3Q+t6MhKsL+i8A0HCT51QCJ+HCd7zK0SNaQtOZmuhgPZuhul8rYXsxlfiKlh3i4/LRcFCXUW23bwZoGu2yjxw7sMVJTXdzYxGlEhigUPhE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781596627; c=relaxed/simple; bh=ynwTYkbeFPjFIm+WHwVrQOCx0rSOLZUBKzgHHtlvDO0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IZQ7B5l1NumXDAUn4aLQFRhJDchNnQiVDaUrVFPB+KrpwdI06DRPAK2mQEPnaIV6fdJ1HVZAAFvIqWhRqAai2BbemVZf0DuuXtSGLd1zmn/Wr69GrgAqupn1EBHZcqiImO6BzFuVLf2w//1HJYdr0DoA2dXeRYNSunWWGpBgB+g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H8pxH6kj; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H8pxH6kj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE3111F000E9; Tue, 16 Jun 2026 07:57:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781596626; bh=ddbGGLF1hS3rZkvnrw1zJSUaQQOcdUHnv1T3/p8dKw8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=H8pxH6kj1IzwWhX3XSZoXl8qYE+bnxXFuoZNsBvvksnnqnH10CoQ3v92TdTqAeICP 11yEOlQXvGK/QJCCZyI+Jjc6Tll+LThZFxrJSUXeEYApzELk0mkgF5tBPzUn+EjT53 1xBlmcMBz0amIYL2D7PiAZjPKVVtGelIDLE5nh7xLjQ4X7h5Tcx83vo8A14Y2ecUQw x5sUZp6j3i+jGmx31DKsHucagpdc+yF1mOLBB4Eimh2mEUeVEH+5wluH/C75prSomB z05vH4wQ4F5I3TfrWdgayO6dHepCpQVp1D49GcRPmBnMXIS7/QfAp5LlV4dsIiiE4n UAyHE5a6Bt8uQ== Date: Tue, 16 Jun 2026 10:56:57 +0300 From: Mike Rapoport To: "zhen.ni" Cc: Andrew Morton , Kairui Song , Qi Zheng , Shakeel Butt , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/sparse: Optimize section number calculations using bit shifts Message-ID: References: <20260616025942.3572473-1-zhen.ni@easystack.cn> <764b8fef-4e77-4daf-b2ba-45745061ade9@easystack.cn> 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: <764b8fef-4e77-4daf-b2ba-45745061ade9@easystack.cn> On Tue, Jun 16, 2026 at 03:29:38PM +0800, zhen.ni wrote: > 在 2026/6/16 14:32, Mike Rapoport 写道: > > On Tue, Jun 16, 2026 at 10:59:42AM +0800, Zhen Ni wrote: > > > > > > Performance improvement: > > > Total: (7538-5641)/7538 = 25.2% faster > > > memblocks_present: (4232-3562)/4232 = 15.8% faster > > > section initialization: (3261-2057)/3261 = 36.9% faster > > > > This is a nice improvement, but it's not the hot path. I believe you can > > derive improvement to __nr_to_section() from these measurements. > > sparse_init() is not a hot path, but it invokes __nr_to_section() in a > tight loop, making it a good measurement point to demonstrate the > performance improvement. Right, and explanation along these lines should be in the changelog. > > > Signed-off-by: Zhen Ni > > > --- > > > include/linux/mmzone.h | 7 +++++-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > > > index 9adb2ad21da5..5daf471f6823 100644 > > > --- a/include/linux/mmzone.h > > > +++ b/include/linux/mmzone.h > > > @@ -2035,11 +2035,14 @@ struct mem_section { > > > #ifdef CONFIG_SPARSEMEM_EXTREME > > > #define SECTIONS_PER_ROOT (PAGE_SIZE / sizeof (struct mem_section)) > > > +#define SECTIONS_PER_ROOT_SHIFT ilog2(SECTIONS_PER_ROOT) > > > #else > > > #define SECTIONS_PER_ROOT 1 > > > +#define SECTIONS_PER_ROOT_SHIFT 0 > > > #endif > > > -#define SECTION_NR_TO_ROOT(sec) ((sec) / SECTIONS_PER_ROOT) > > > +#define SECTION_NR_TO_ROOT(sec) ((sec) >> SECTIONS_PER_ROOT_SHIFT) > > > +#define SECTION_NR_IN_ROOT(sec) ((sec) & SECTION_ROOT_MASK) > > > #define NR_SECTION_ROOTS DIV_ROUND_UP(NR_MEM_SECTIONS, SECTIONS_PER_ROOT) > > > #define SECTION_ROOT_MASK (SECTIONS_PER_ROOT - 1) > > > @@ -2065,7 +2068,7 @@ static inline struct mem_section *__nr_to_section(unsigned long nr) > > > if (!mem_section || !mem_section[root]) > > > return NULL; > > > #endif > > > - return &mem_section[root][nr & SECTION_ROOT_MASK]; > > > + return &mem_section[root][SECTION_NR_IN_ROOT(nr)]; > > > > The explicit masking is clearer IMO. > > > > > } > > > extern size_t mem_section_usage_size(void); > > > > Hmm, I don't see BUILD_BUG_ON() you mention in the changelog. > > > -- > > > 2.20.1 > > > > > > > Regarding the BUILD_BUG_ON, it is in sparse_init() at line 419: > > void __init sparse_init(void) > { > ... > /* see include/linux/mmzone.h 'struct mem_section' definition */ > BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section))); > ... > } > > This guarantees that sizeof(struct mem_section) is a power of 2, and since > SECTIONS_PER_ROOT = PAGE_SIZE / sizeof(struct mem_section) and PAGE_SIZE is > always a power of 2, SECTIONS_PER_ROOT is guaranteed to be a power of 2 as > well, validating the use of bit shifts. This was not clear from reading the changelog. > Thanks, > Zhen -- Sincerely yours, Mike.