From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B0E7D443307 for ; Wed, 15 Jul 2026 15:52:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784130748; cv=none; b=aDD8cq9/WxhChljASAmToQChOKqvhGk4E+PW6lWjDlmE1JO+Wce6JZ2oF9hfnuFLbd47OFI1b2vb9X727bqOoc9rDqfHE2WWdJBrcOlaCJujYSxkoNis3oJHrrRCyocIK0jX1a5DsnSRxwkonc9Hr0II54JHpuXQaVGTzc3pEQU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784130748; c=relaxed/simple; bh=A6D5/P7nWhqv02nuZMgT/J+Bv0fyy8Idtv95M0RhQlo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BRdFu/FBnixZCgarFYgyDp481ODUIZiKfXU10oRkLQPXiH0rt+I6KlDCrrlsQ3P7RjIg23QjE1903JDAVxaOmRJAxLLfA9PzK9D+IkooZiVATd212AC//9qrBrRVc+ZNFfRsHaUlEH0FBXCkEBRhUs93g8VS7dApxSWZR6SX0xM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=qyru0Eep; arc=none smtp.client-ip=209.85.221.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qyru0Eep" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-4703bc0a99aso3514678f8f.3 for ; Wed, 15 Jul 2026 08:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784130744; x=1784735544; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=sWgBpxHnWpKz04YeWJzaau0+Llvhi6GnlbNod4OskE8=; b=qyru0EepUPBJCmYMUKaB/z4cOg+jpVaEamk3sHo3qLCKzPSLEkAEonuS2z7HR9F5WK XOAvdODOeNhSNHOYRnalnN6qc2A3yVrWn9LL3gJxFzTsH5NdQ3I/ZG0IwxQGNEHWC3iY yjId1FVt2MqUiidDfDcO2FQXil6TB3+xwABVQkMXQRlZvg3hDXekrwUc8R/lyVnj+1QR jgTPD+s772DcUdWgrLuq5ZKWj8HWKrpG8iSk9XZhSPB0SW//vNYH4j5P2rxOOpAITRw3 UIc8HSdv+SbJta8bt/K9SeHjJphSOk9QN234I5cpsZWXo8RYo+xkoQS8+sHFALAYq03W zk/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784130744; x=1784735544; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=sWgBpxHnWpKz04YeWJzaau0+Llvhi6GnlbNod4OskE8=; b=VxyeOqD6EJt442MvMW60gozM3ZQB2OuJAzGUysygOsqtYMJGqCPbVMZUOiAyHOaVq9 w41gU9XxL3swlbrNQiRTtH8DWV/A59DrX8j3dmrZsxuW64KzqseQz4wh5h0aRr/x6iqN STiVha4zSVMl62pmEoA8fD+/gSBvHMLIQZSJBuVBuv7tAo+rD6vZO38UDrp1ZYxRwAR9 rj50EtHQV4opBD1r8BTDvFEx1A2TBYYQA3UMoG5gg3qCy0woNPecO2ZcCsCcQY0wH0/j 6X605gd7tucOO+ZM6WEtqpVLncy7RzStP+mwbAJe1AsWorI04CXpqNVDeQMUcRukdRS7 qXCg== X-Forwarded-Encrypted: i=1; AHgh+RrSrKwXTu7mPkvR8DTHnO1VKhftIunGrjRcncm4SOIGikQq/fdXl2WT7gfSbnlobNJAS4nAGkpAU3B16WE=@vger.kernel.org X-Gm-Message-State: AOJu0YzpuQEwbduwD/nfCnXD6vJe4wJekvVZfLzxURMtmSeMdqG20jh9 S41kobFsOn9H9zgk8s5w3fj96VeMWBvTjQZHuyd9ELzgaz/eU7zbSukI X-Gm-Gg: AfdE7cnovW1ZTPANlHysVCSRKaS7XJ42Q45PS49e6TcqtmS7bToydnI71lRCeUNXa/K iJSrZ10EeBh6Y7QJZ6OruBHPxJ4g0Vyww1cqTb+iX7P023yB0RC+UMDQAoMqrJZnMudzBW44FoH ZJpQJY/kMLmaFzXsdWB6A1ZJ1BBYv3lAZdIK8SJvn/mpf93OKk0VwiiFNuU+3Kph8x5tlv0HSKt 5gIvoGFkgCvXvzRPe1jItkVPfEfhlZxnAQjsbSy4vcye0ZmiLRnLCkkiHQsFcXyQmEHnC8TFM6x 1Nc4LOv9s3kNe3F5xBDfjLG3FiyL+FhSS9lghTCPSXeZzOeqWYVQIJK2wNBbIS/EvtQ4zxDp6GS PB7XKCKxrmLBjR1b6BGfa/2MZI607SixJ9bFHmuXUet4M5+S4VJm0z4oJu5Zkqw45i4Ajv33/fv OKnsfZ4W+5uB1PlQyFV8pishaO6ybHX2ncdOaKbj2mpjstgtLK9Q== X-Received: by 2002:a05:6000:46c2:b0:47f:5298:a010 with SMTP id ffacd0b85a97d-47f5298a31emr2117677f8f.41.1784130744504; Wed, 15 Jul 2026 08:52:24 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f464c30a9sm16692342f8f.31.2026.07.15.08.52.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2026 08:52:24 -0700 (PDT) Date: Wed, 15 Jul 2026 16:52:22 +0100 From: David Laight To: Muchun Song Cc: Muchun Song , Andrew Morton , Oscar Salvador , David Hildenbrand , linux-mm@kvack.org, Mike Rapoport , Vlastimil Babka , Lorenzo Stoakes , Michal Hocko , linux-kernel@vger.kernel.org Subject: Re: [PATCH 01/17] mm/sparse: drop power-of-2 size requirement for struct mem_section Message-ID: <20260715165222.0164a76c@pumpkin> In-Reply-To: <71E70E00-98A1-4769-A167-5F4CB59EC96B@linux.dev> References: <20260702093821.2740183-1-songmuchun@bytedance.com> <20260702093821.2740183-2-songmuchun@bytedance.com> <20260715103445.31b2f727@pumpkin> <71E70E00-98A1-4769-A167-5F4CB59EC96B@linux.dev> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: quoted-printable On Wed, 15 Jul 2026 21:15:45 +0800 Muchun Song wrote: > > On Jul 15, 2026, at 17:34, David Laight = wrote: > >=20 > > On Thu, 2 Jul 2026 17:38:05 +0800 > > Muchun Song wrote: > > =20 > >> struct mem_section is currently forced to a power-of-2 size so the > >> section-to-root lookup can use a mask instead of a modulo. > >>=20 > >> That requirement adds configuration-dependent padding, especially with > >> CONFIG_PAGE_EXTENSION, just to preserve the lookup scheme. > >>=20 > >> Drop the constraint and use a plain modulo for the lookup instead. The > >> divisor is constant, so the generated code remains cheap while avoiding > >> the extra padding. It also removes an unnecessary layout constraint > >> from the type. =20 > >=20 > > This has a side effect of changing the size of the 'section' from > > PAGE_SIZE to something 'a bit smaller' when CONFIG_PAGE_EXTENSION > > is defined. > > I don't think it actually matters, the allocation is done by: > >=20 > > static noinline struct mem_section __ref *sparse_index_alloc(int nid) > > { > > struct mem_section *section =3D NULL; > > unsigned long array_size =3D SECTIONS_PER_ROOT * > > sizeof(struct mem_section); > >=20 > > if (slab_is_available()) { > > section =3D kzalloc_node(array_size, GFP_KERNEL, nid); > > } else { > > section =3D memblock_alloc_node(array_size, SMP_CACHE_BYTES, > > nid); > >=20 > > so the size might get rounded up to PAGE_SIZE anyway. =20 >=20 > I'm not sure I really understand what you mean. You might be asking wheth= er > the reduction in the size of the `mem_section` structure does not actuall= y result > in memory savings? If so, please let me explain clearly. As you mentioned= , the > size of memory allocated each time here should be PAGE_SIZE. Before the > modification, one page could hold 4096/32 =3D 128 `struct mem_section` in= stances; > with the modified code, the number of `struct mem_section` instances that= can fit > is 4096/24 =3D 170. Therefore, the range of memory sections that a PAGE_S= IZE can > cover has increased 32%. >=20 > Please let me know if I didn=E2=80=99t get your point. 170 * 24 is 4080 - 16 bytes less than PAGE_SIZE. In principle kmalloc() need not allocate a full page for it which would lead to the data crossing a page boundary - which may not be intended. >=20 > >=20 > > I also suspect that '% 24u' might be enough slower than '% 32u' to > > generate a measurable performance drop. > > (It doesn't matter whether you do '& 31' or '% 32u'.) =20 >=20 > David, I agree that % 24u is slower than % 32u =E2=80=94 the latter maps = to =E2=80=98and', while the > former requires a multiply-shift sequence. However, since the divisor is = a constant, > the compiler should uses the magic multiplier approach at -O2, which is ~= 3-5 cycles > instead of 1. So I think the per-lookup overhead is real but small. The divide/remainder is by 170 not 24 - but the effect is the same. Indeed, but it might be a hot enough path to be measurable. I've just done a pile of test compiles, see https://godbolt.org/z/zq8WjaqGj The remainder code has to do the divide, gcc might notice it has already done it - but it would be better to do it explicitly. However, both sparc64 and looooongarch64 end up executing divides. Also some of the others aren't as short as you might expect, both generating the constant for the multiply and avoiding a 'mul' instruction for the remainder (esp. s390). David >=20 > Thanks for your review. >=20 > Muchun >=20 > >=20 > > David =20 >=20