Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp639377pxb; Tue, 1 Feb 2022 07:29:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJxkihH1R/LX8hAEc6SdKBIZcIHNssXUzLzL33GkPBS64Zsyes64UBRHJYRyhWq6vSKeL9Lu X-Received: by 2002:a63:4650:: with SMTP id v16mr21245416pgk.155.1643729353036; Tue, 01 Feb 2022 07:29:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643729353; cv=none; d=google.com; s=arc-20160816; b=iDocv1FGr1BmcCDGyX20Fnzvr/atl3YXDxOOIEYfpSUci7PsXwLbCvQppSP65Tq/8O xfjumaLzstYmwMusqCLMjWv0XTysMPiohqQ6Ae4vwaImdpAntc21gSxJmeCU8pK8FfCl 6kdMlxW/dCiTBLAqwFywn8lors9GP+pprIg+fq+Pwqv92uzYYnIRLa+X8YRS6rLo2pHw WDdmOaxbgoW7b183OVIJe/4V16SV7JmMuc5nmQPgJxu3Y4/YMTbs0HrpcBuLpGCyrhMI TdLvF5gwoz00dOUHbWnLXrfd7zGrs2f6wikPO/3l2A6t525cNa1SvGbkxDuA5sTV2UOs tOLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=glFJZo9ETm7z/ROJWLizrW+pr8HZoGe/q8WkURW8RkQ=; b=RUw/ETjJzJKLRfd4Hdsqd2mh+ljKsFpsCyjE2MpzsKfgVge73NyCDOLy3CRP9Etvw0 9ZFzd+8h2iM7jTe17ZHPOd9odH2yHf80Kot/LiHLYnpqwxohWqsKIPEmNbk+0Y8DCX7Z g1JA5l7rmFnXNGLaeHg8pc4GhMz02VwylfFHK6lKpukOZBtn3+8bvif7pEe3uDsY8/eD Ft3a2fsEE7Hg49ECTdfFekaCQmTKEpp++/A5NPPguU5oelZ1Rkc3FkLVKZdBBPIAHh8D kfUaAxF68duMBZXTk8Kpu6wKdojhFHMJHMTuN+Sh8fXDG4rXFl1UKwlk9du8mn3IDkQ8 9WQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=w8KMAEvy; dkim=neutral (no key) header.i=@suse.de header.b=TDQphaJN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y2si16989621plg.43.2022.02.01.07.29.00; Tue, 01 Feb 2022 07:29:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=w8KMAEvy; dkim=neutral (no key) header.i=@suse.de header.b=TDQphaJN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235690AbiAaGXK (ORCPT + 99 others); Mon, 31 Jan 2022 01:23:10 -0500 Received: from smtp-out1.suse.de ([195.135.220.28]:35030 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235225AbiAaGXI (ORCPT ); Mon, 31 Jan 2022 01:23:08 -0500 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 622DD21116; Mon, 31 Jan 2022 06:23:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1643610186; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=glFJZo9ETm7z/ROJWLizrW+pr8HZoGe/q8WkURW8RkQ=; b=w8KMAEvyM5acD//MgH4CajE1JEJz8SxcqA0XTBpjOLdP3Y3DfOPgmknPgt6vMEQSu2UxKr u3k9g5AC6FK3rteUS6oQ2W4X6pdLAj2nmcydWV74bIC4MaopLhoOsqvmK/IQCZkgUjj+nU t+q5jmvCPZIh0ma+eKW6RgMXyvuYuxQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1643610186; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=glFJZo9ETm7z/ROJWLizrW+pr8HZoGe/q8WkURW8RkQ=; b=TDQphaJNby4XljQkkKeL0ahZQdHJQgHaQp8Z41WoJRUMdR2cjZ5r7SYEkGg5JZegoMuWcn bVZwx8tB3cZ/YtBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4E00713A89; Mon, 31 Jan 2022 06:23:04 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id kb0eD0iA92GYMAAAMHmgww (envelope-from ); Mon, 31 Jan 2022 06:23:04 +0000 Date: Mon, 31 Jan 2022 07:23:02 +0100 From: Oscar Salvador To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Greg Kroah-Hartman , Michal Hocko , Catalin Marinas , Will Deacon , Thomas Bogendoerfer , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Paul Walmsley , Palmer Dabbelt , Albert Ou , Heiko Carstens , Vasily Gorbik , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "Rafael J. Wysocki" , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org Subject: Re: [PATCH RFC v1] drivers/base/node: consolidate node device subsystem initialization in node_dev_init() Message-ID: References: <20220128151540.164759-1-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220128151540.164759-1-david@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 28, 2022 at 04:15:40PM +0100, David Hildenbrand wrote: > ... and call node_dev_init() after memory_dev_init() from driver_init(), > so before any of the existing arch/subsys calls. All online nodes should > be known at that point. > > This is in line with memory_dev_init(), which initializes the memory > device subsystem and creates all memory block devices. > > Similar to memory_dev_init(), panic() if anything goes wrong, we don't > want to continue with such basic initialization errors. > > The important part is that node_dev_init() gets called after > memory_dev_init() and after cpu_dev_init(), but before any of the > relevant archs call register_cpu() to register the new cpu device under > the node device. The latter should be the case for the current users > of topology_init(). So, before this change we had something like this: do_basic_setup driver_init memory_dev_init do_init_calls ... topology_init register_nodes/register_one_node And after the patch all happens in driver_init() driver_init memory_dev_init node_dev_init I guess this is fine as we do not have any ordering problems (aka: none of the functions we used to call before expect the nodes not to be there for some weird reason). So, no functional change, right? This certainly looks like an improvment. -- Oscar Salvador SUSE Labs