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]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1B2ACD4F2F for ; Wed, 4 Sep 2024 20:41:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3737E6B0106; Wed, 4 Sep 2024 16:41:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3244E6B0131; Wed, 4 Sep 2024 16:41:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EC326B0132; Wed, 4 Sep 2024 16:41:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id F383B6B0106 for ; Wed, 4 Sep 2024 16:41:08 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 933A61403D5 for ; Wed, 4 Sep 2024 20:41:08 +0000 (UTC) X-FDA: 82528225416.29.C43A74C Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf13.hostedemail.com (Postfix) with ESMTP id DC3EA20005 for ; Wed, 4 Sep 2024 20:41:05 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=MpduPxhc; spf=pass (imf13.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725482369; h=from:from:sender: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:dkim-signature; bh=O7Lth0NYCW29OxZ82F4YxxLf2DDgz85hPWGoBlRqbTc=; b=sKN0mAp3ttWYcXYB64Xvm4Mcfp5nrdpbtwJdFzXZY03Mt/uyAMFGOIt+PsmlxhTaBXr8nG DJTWVE8TsNnOQQk8WKwONfz97nTIloj+vvJEAOu6WxDnj+7GbJgdQexqygP7W7ogyn/u7l g9OzNLs0/Hp03k/kT+BnecDy+qoT0YI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725482369; a=rsa-sha256; cv=none; b=BokJf8tVx36NDobVLUs0Btl/7gfyBsPXCdVM25cXwrEu16n5Z89A8F4JZVSS2JnTNAxhrH Q7dCj1XskqVgo1LStxq/0qzaVpoZ1qEH1BkKzX3fMghvS+W1yTVAl12bjk6bv45IAW1L5z lRYTKVv6dhrR5PGe62OfiGxJioab2VE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=MpduPxhc; spf=pass (imf13.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id BEF0CA4495A; Wed, 4 Sep 2024 20:40:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46A6BC4CEC2; Wed, 4 Sep 2024 20:41:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1725482464; bh=RtHzb2/2jf4vevAr8HjFhrLQINYyj6MKSGehMrPg02M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MpduPxhcQ3ZWy9hqnZYGup2B22fv+BFtCDYriisMpmcv5Y2F64IzAu3ZEj1B+CmOh C0BCQViaeg3lbNDJ5783Sa6kA6VBWFpJIX7LOcYrgDzZMMeMxzPzG1Kp7lDeRg71DR OGdRDwfAiqyJ25ulC8qckIUkHnenQpDDaCOY1Xkc= Date: Wed, 4 Sep 2024 13:41:02 -0700 From: Andrew Morton To: Qiang Liu Cc: rppt@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/mm_init.c: add zidcache to the init_reserved_page function Message-Id: <20240904134102.a7171fb6676dd95dc3b8ede7@linux-foundation.org> In-Reply-To: <20240904115541.6519-1-liuq131@chinatelecom.cn> References: <20240904115541.6519-1-liuq131@chinatelecom.cn> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DC3EA20005 X-Stat-Signature: xabcw7xtydtsh64884bntxp1n17scdr1 X-HE-Tag: 1725482465-231032 X-HE-Meta: U2FsdGVkX19QxHyglEXnILPC6YSxDTJen2zsIxy21WFu6WtFVNemie4+4vxhkl6wQQrxVTGLaWz+egzDUKyRPJzkEt3i0kJMO5NICWpYOOVpmg+8hAzq5XsCertzhbncDz6ZZpEoCfbmZDW1L33oEIRy1hrqdXv36V56B1g9o9Wgx7r/cF8ekWLcs2BV02kGi6agtYWclvjDa0u1AsK7W+nSZQP0PKGTNRd/2pF9b4VijiOwPhisCUes4cuhZpogGw1m9HxvL/6AW/W31WAWxL0UpfhTF3CEi0nLsxjBjdo0WQwL/t8/oShb2al1UX16j5InK00Ah6lklAxIEUSFisWmkwLWzroG7CFs97deRq6YZw1strPS4TEjiElGASFRygHqOXAcrfkAHZzlYMZpJtotmCQXKrMWtaCujNHYaBJ2KddnWtBPmUTm3CZMRcGcO+djrYO/6BxkpKXwbeTUoOwRX7eipkFJE1v81x0xgWOHxDpyVGCZcjpWtt626gLcn4Ml7sPO/kYdbkAc98O6KHc9taZnT3W6RukheCaiW+MuF3Qe4XtnoWwPUvTvDExfy0mOSHaejIWqRSruMzM+XQVYgjgg66vCQvxax8Sy2kqN7LD0z3lmRhDI2ck8lmNSoJpPo6h3daX6M86yK933+GnuPgD+LgGJS7rG4wyhGa49tUOLG+JuoUud+aw9RjfMayNapxvS5fzfbtP0d41JwEaobqLbxWC9i9qrMKLxbQe9hNan7ixTTGWY2BQOa0w4+k4fnRpVvTQcbs6DU1rr6CCDfpSX/eBIgH7dQAOxHTXy7KRkqUj7gP5nRHTAKMppX3AG5nNKse+2r64URE9smyQ7h2RpzvnRfY1eFTFX2Vo1hhVTkcii0DbcVeXHUxhGHZ7pboxzBsjjdsrWOTCNb1DKR1FhDe+JYlZakBhFc2t5p9SOv7jbE4bDfKs4fFbNLqsj102txD8GCxxtSvr 8Dhh/4nj /XympZl4wSHisLRY0fPGdSJ2kC1JUAyvlzX1b4m8lxGzcab+6T2CBp3rvN0tehi+uP64tOpkTWoyEdCJcm3QEUC5Qg3xrvkpbP0QdGVPNN5JaxEhA5sZ8wgDuUkWQElP3mpxya1c2ACR/JE/7atNXZUpnxZsF6Lq7L5CbIJmSxoUpdLFlDQSZOAmD0JBGunWPXVH1SlS6supHqlyogmOwMAUJULrQeUY3CbotOU8ysDxf3gRbjqb6wlxGJTdCif6yjQL3VxRXrkA/6UoK1EQEuX4GqAFWXDMxtvVFAKOnL7u9EWo= 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 Wed, 4 Sep 2024 19:55:41 +0800 Qiang Liu wrote: > Each call to the init_reserved_page function will look up the > corresponding zid for the given pfn parameter. Even if subsequent > calls have the same zid for the pfn as the current one, the lookup > will be repeated. > > During system initialization, the memmap_init_reserved_pages function > calls init_reserved_page for each contiguous memory region in mem_region. > Implementing a cache for zid can significantly improve performance. > Tests have shown that adding a zid cache reduces the execution time of > the memmap_init_reserved_pages function by over 7%. > OK, but how much speedup do we see overall? In other words, is memmap_init_reserved_pages() a significant consumer of execution time? I'd be surprised if it makes much difference at all - MAX_NR_ZONES is a small number. Maybe we call init_reserved_page() a lot. > --- a/mm/mm_init.c > +++ b/mm/mm_init.c > @@ -710,19 +710,25 @@ static void __meminit init_reserved_page(unsigned long pfn, int nid) > { > pg_data_t *pgdat; > int zid; > + struct zone *zone; > + static int zidcache; What locking protects zidcache? lock_device_hotplug() and/or __init-time serialization? This might be worth mentioning? > > if (early_page_initialised(pfn, nid)) > return; > > pgdat = NODE_DATA(nid); > > - for (zid = 0; zid < MAX_NR_ZONES; zid++) { > - struct zone *zone = &pgdat->node_zones[zid]; > + zone = &pgdat->node_zones[zidcache]; OK, but if init_reserved_page() was previously called against a different node, `zidcache' will refer to a zone in a different node. The code will work OK, but it's worth mentioning somewhere I guess. > + if (unlikely(zone_spans_pfn(zone, pfn))) Isn't this wrong? We need to redo the search if !zone_spans_pfn(...)? > + for (zid = 0; zid < MAX_NR_ZONES; zid++) { > + zone = &pgdat->node_zones[zid]; > > - if (zone_spans_pfn(zone, pfn)) > - break; > - } > - __init_single_page(pfn_to_page(pfn), pfn, zid, nid); > + if (zone_spans_pfn(zone, pfn)) { > + zidcache = zid; > + break; > + } > + } > + __init_single_page(pfn_to_page(pfn), pfn, zidcache, nid); > } > #else > static inline void pgdat_set_deferred_range(pg_data_t *pgdat) {} > -- > 2.27.0