[v2,06/14] init: fold build_all_zonelists() and page_alloc_init_cpuhp() to mm_init()
Message ID | 20230321170513.2401534-7-rppt@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp1911843wrt; Tue, 21 Mar 2023 10:33:01 -0700 (PDT) X-Google-Smtp-Source: AK7set+ki4igIEIALRadPONHsM5Ww9Ao8sq5RphmaC124K2Eu+QrdbqhwlnVCPhOK/C6IOqK++LN X-Received: by 2002:a17:902:da90:b0:19c:fd9e:f88c with SMTP id j16-20020a170902da9000b0019cfd9ef88cmr3831255plx.18.1679419981248; Tue, 21 Mar 2023 10:33:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679419981; cv=none; d=google.com; s=arc-20160816; b=My3YKgLHV+21D1SMnO7Tp66MwK7xac5rX+BUMH1xWILdGC7d9ZUfgA+62935BNCI+u E+YQ1VKT/STShalQgDf+D5LG1KJ4issEDyJirCIIbgPURwO7vXsBa286YRrr7uy3eKWP V9pZ+DXoJzrfye8y67rjzWqLWIEkn4K1tITT78V9GPzcVif1cY51u0Na/Ipa/DhxsCi8 UHyhkL8zcnpstsaLToBr5LgbLW0FEKhO40shI1W7RutnzlW7I2YribRta8guRDv+TKA6 0yI65fncAiUh85PDRLhN4oDunZwOevhCudi3+ZIHTXve28ID/72Da1p89bv9oyHCs1AJ V2wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=UkIaXt+ePedAKBmi84zwc0JbiwWbm2uBq3ujDVLhM+k=; b=xlauZS17XXE9jWyFhJl51QUAtHaDS9Zi/pcdAtbQUaxtxnv/Lck+HnGaU0JdpcyJFa FaIEjMCHsssgQujobykZAodcXn5+RwSlcoywIGdJyS8/dr6SQkrkhYYeNc0+0BtXRTNV T9X9d3dZePD3N9P25tfU3BpbymtD26n8eCkWCNL2NnOQn/K/rPbqkA99M/I5szlhj9i6 4wnNkJkCZ1lKf3IcWTcKIinj3xM5nq/swj0fdPnnQL6zBOu6jH5xFeTeJVIsaq4TsJpl xIDiovOSv9zVYRDQwig1UdV9Jd8TTG8hWrJF11Eo8wvyAHuh4afzQLjV2nOyWY5Rt7xG Y1BA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VV0W2zZW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c20-20020a6566d4000000b0050f66d3f72csi8358771pgw.532.2023.03.21.10.32.48; Tue, 21 Mar 2023 10:33:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VV0W2zZW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231127AbjCURGr (ORCPT <rfc822;ezelljr.billy@gmail.com> + 99 others); Tue, 21 Mar 2023 13:06:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230487AbjCURGP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Mar 2023 13:06:15 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FEA5532BF; Tue, 21 Mar 2023 10:05:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4B44AB818B9; Tue, 21 Mar 2023 17:05:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5914C433EF; Tue, 21 Mar 2023 17:05:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679418352; bh=PM92BQVLa2WxBbnDUdLvSknVaFsEpK5ocCyJK48uW0c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VV0W2zZWcfrS0Pnp7+uSdWblosvpxij7nM1hHcrlG6KllIxLpgkWjfxg6L8pJn6fS BuLcNFnrrsqJZ2HjcQZgwa16TIsHGm+PlSEnS618ROJunWIwJUgEEKS9BmC8kn9mtZ +a/7bhMFsF80Ers2bOuy4wk2Hv6uXB6fN16IauXtYO3TdhOGMD2w+MVQYE18Gy8lNX I0UmErrOkPo74b4zSg9+e3g/fu3Q03+8nBlqGdPNQDWEi47Z/ABd4ZcARfsXP8gp/4 en9kBBqp2MCxbotDylFJMqcRb66FWu2xCKl7T8IUAf9yteeqDDhCD3NcqHA5r7EPKp 9OrwGIUQYSbLQ== From: Mike Rapoport <rppt@kernel.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: David Hildenbrand <david@redhat.com>, Doug Berger <opendmb@gmail.com>, Matthew Wilcox <willy@infradead.org>, Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>, Mike Rapoport <rppt@kernel.org>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Vlastimil Babka <vbabka@suse.cz>, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v2 06/14] init: fold build_all_zonelists() and page_alloc_init_cpuhp() to mm_init() Date: Tue, 21 Mar 2023 19:05:05 +0200 Message-Id: <20230321170513.2401534-7-rppt@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20230321170513.2401534-1-rppt@kernel.org> References: <20230321170513.2401534-1-rppt@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760999486067370299?= X-GMAIL-MSGID: =?utf-8?q?1760999486067370299?= |
Series |
mm: move core MM initialization to mm/mm_init.c
|
|
Commit Message
Mike Rapoport
March 21, 2023, 5:05 p.m. UTC
From: "Mike Rapoport (IBM)" <rppt@kernel.org> Both build_all_zonelists() and page_alloc_init_cpuhp() must be called after SMP setup is complete but before the page allocator is set up. Still, they both are a part of memory management initialization, so move them to mm_init(). Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org> Acked-by: David Hildenbrand <david@redhat.com> --- init/main.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Comments
On 3/21/23 18:05, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" <rppt@kernel.org> > > Both build_all_zonelists() and page_alloc_init_cpuhp() must be called > after SMP setup is complete but before the page allocator is set up. > > Still, they both are a part of memory management initialization, so move > them to mm_init(). Well, logic grouping is one thing, but not breaking a functional order is more important. So this moves both calls to happen later than theyw ere. I guess it could only matter for page_alloc_init_cpuhp() in case cpu hotplugs would be processed in some of the calls we "skipped" over by moving this later. And one of them is setup_arch()... so are we sure no arch does some cpu hotplug for non-boot cpus there? > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org> > Acked-by: David Hildenbrand <david@redhat.com> > --- > init/main.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/init/main.c b/init/main.c > index b2499bee7a3c..4423906177c1 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -833,6 +833,10 @@ static void __init report_meminit(void) > */ > static void __init mm_init(void) > { > + /* Initializations relying on SMP setup */ > + build_all_zonelists(NULL); > + page_alloc_init_cpuhp(); > + > /* > * page_ext requires contiguous pages, > * bigger than MAX_ORDER unless SPARSEMEM. > @@ -968,9 +972,6 @@ asmlinkage __visible void __init __no_sanitize_address start_kernel(void) > smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */ > boot_cpu_hotplug_init(); > > - build_all_zonelists(NULL); > - page_alloc_init_cpuhp(); > - > pr_notice("Kernel command line: %s\n", saved_command_line); > /* parameters may set static keys */ > jump_label_init();
On Wed, Mar 22, 2023 at 05:10:10PM +0100, Vlastimil Babka wrote: > On 3/21/23 18:05, Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" <rppt@kernel.org> > > > > Both build_all_zonelists() and page_alloc_init_cpuhp() must be called > > after SMP setup is complete but before the page allocator is set up. > > > > Still, they both are a part of memory management initialization, so move > > them to mm_init(). > > Well, logic grouping is one thing, but not breaking a functional order is > more important. So this moves both calls to happen later than theyw ere. I > guess it could only matter for page_alloc_init_cpuhp() in case cpu hotplugs > would be processed in some of the calls we "skipped" over by moving this > later. And one of them is setup_arch()... so are we sure no arch does some > cpu hotplug for non-boot cpus there? mm_init() happens after the point build_all_zonelists() and page_alloc_init_cpuhp() were originally, so they are essentially moved later in the init sequence and in either case called after setup_arch(). We skip the code below and it does not do neither cpu hotplug nor non-memblock allocations. jump_label_init(); parse_early_param(); after_dashes = parse_args("Booting kernel", static_command_line, __start___param, __stop___param - __start___param, -1, -1, NULL, &unknown_bootoption); print_unknown_bootoptions(); if (!IS_ERR_OR_NULL(after_dashes)) parse_args("Setting init args", after_dashes, NULL, 0, -1, -1, NULL, set_init_arg); if (extra_init_args) parse_args("Setting extra init args", extra_init_args, NULL, 0, -1, -1, NULL, set_init_arg); /* Architectural and non-timekeeping rng init, before allocator init */ random_init_early(command_line); /* * These use large bootmem allocations and must precede * kmem_cache_init() */ setup_log_buf(0); vfs_caches_init_early(); sort_main_extable(); trap_init(); > > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org> > > Acked-by: David Hildenbrand <david@redhat.com> > > --- > > init/main.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/init/main.c b/init/main.c > > index b2499bee7a3c..4423906177c1 100644 > > --- a/init/main.c > > +++ b/init/main.c > > @@ -833,6 +833,10 @@ static void __init report_meminit(void) > > */ > > static void __init mm_init(void) > > { > > + /* Initializations relying on SMP setup */ > > + build_all_zonelists(NULL); > > + page_alloc_init_cpuhp(); > > + > > /* > > * page_ext requires contiguous pages, > > * bigger than MAX_ORDER unless SPARSEMEM. > > @@ -968,9 +972,6 @@ asmlinkage __visible void __init __no_sanitize_address start_kernel(void) > > smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */ > > boot_cpu_hotplug_init(); > > > > - build_all_zonelists(NULL); > > - page_alloc_init_cpuhp(); > > - > > pr_notice("Kernel command line: %s\n", saved_command_line); > > /* parameters may set static keys */ > > jump_label_init(); >
On 3/22/23 21:26, Mike Rapoport wrote: > On Wed, Mar 22, 2023 at 05:10:10PM +0100, Vlastimil Babka wrote: >> On 3/21/23 18:05, Mike Rapoport wrote: >> > From: "Mike Rapoport (IBM)" <rppt@kernel.org> >> > >> > Both build_all_zonelists() and page_alloc_init_cpuhp() must be called >> > after SMP setup is complete but before the page allocator is set up. >> > >> > Still, they both are a part of memory management initialization, so move >> > them to mm_init(). >> >> Well, logic grouping is one thing, but not breaking a functional order is >> more important. So this moves both calls to happen later than theyw ere. I >> guess it could only matter for page_alloc_init_cpuhp() in case cpu hotplugs >> would be processed in some of the calls we "skipped" over by moving this >> later. And one of them is setup_arch()... so are we sure no arch does some >> cpu hotplug for non-boot cpus there? > > mm_init() happens after the point build_all_zonelists() and > page_alloc_init_cpuhp() were originally, so they are essentially moved > later in the init sequence and in either case called after setup_arch(). Right, I looked at a wrong place in start_kernel() for the original location of the calls, sorry for the noise. > We skip the code below and it does not do neither cpu hotplug nor > non-memblock allocations. > > jump_label_init(); > parse_early_param(); > after_dashes = parse_args("Booting kernel", > static_command_line, __start___param, > __stop___param - __start___param, > -1, -1, NULL, &unknown_bootoption); > print_unknown_bootoptions(); > if (!IS_ERR_OR_NULL(after_dashes)) > parse_args("Setting init args", after_dashes, NULL, 0, -1, -1, > NULL, set_init_arg); > if (extra_init_args) > parse_args("Setting extra init args", extra_init_args, > NULL, 0, -1, -1, NULL, set_init_arg); > > /* Architectural and non-timekeeping rng init, before allocator init */ > random_init_early(command_line); > > /* > * These use large bootmem allocations and must precede > * kmem_cache_init() > */ > setup_log_buf(0); > vfs_caches_init_early(); > sort_main_extable(); > trap_init(); > Yeah, that looks safe. >> > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org> >> > Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
diff --git a/init/main.c b/init/main.c index b2499bee7a3c..4423906177c1 100644 --- a/init/main.c +++ b/init/main.c @@ -833,6 +833,10 @@ static void __init report_meminit(void) */ static void __init mm_init(void) { + /* Initializations relying on SMP setup */ + build_all_zonelists(NULL); + page_alloc_init_cpuhp(); + /* * page_ext requires contiguous pages, * bigger than MAX_ORDER unless SPARSEMEM. @@ -968,9 +972,6 @@ asmlinkage __visible void __init __no_sanitize_address start_kernel(void) smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */ boot_cpu_hotplug_init(); - build_all_zonelists(NULL); - page_alloc_init_cpuhp(); - pr_notice("Kernel command line: %s\n", saved_command_line); /* parameters may set static keys */ jump_label_init();