[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PATCH v2 07/24] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Hirokazu Takahashi <taka@xxxxxxxxxxxxx>
- Date: Mon, 8 Jun 2026 04:37:57 +0000
- Accept-language: ja-JP, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r/cuMG8nOimg2HUJXyvzjdNtaNyN9qEWk//NCJZQmeY=; b=fHvxPbXP/oxtIp8xDox7+BdfFr10QRRnlUh7gKVqMItGF9qEgyLxEWkVAJLTPhpQpXFz4f0BFRHkYZWVdMKTq9FXufMvgivTobApTrhreqh3Fofc2/YoI2O+xCwDFjzyK94mp0u/BMZfGAvjcsGFUVG0o0al4mv/WwIYeeBFdizb7DV6OTm4akAGeOMpBFIE3UnYK3kp4cggwULvUeGRqp0EZOiDAXDVrJ9zwb+H8eUcg6Cp/uzTBvh5TQopIns+tuM0Opm7y5+w36RFLMq2+SIwe/j9303Np+QRbgIYLVwYBw0QbMwl6YtN5VDArzRtRHtCuW6qQn2dS7fZBp+pOQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eFZTHNQVR4bM6EFOVDseAaMbT/lVDztP80wakxJanoprye3Kqu6GEuNtA/2LJRXwc+XZKHdjLGJrQVDX2b4nUyHDBusleEufqUEYehVwpdWyiZapd2ed0zIFh6j26qgLsx4LzzUBFk97s+IUuKXiWgCxqP3OYzEcq36ZShNu60K9ZAo9fOI52SgznuDtYfUlptLCvIE5RDpy5kZE9eturY4oOG5NNKfML33chEPzhVYluFHS9w2wZU9DyT7C/wKfpee6JPybUPq6FgcwB6qzEffwW5BQHrJiSamifZjK60z7Lbp/92VOOwKEMsB5/FSHrB8vjrHfMZkIx5g/IeU5Qw==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 08 Jun 2026 04:38:12 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHc8U+PsZhvkHY9vEqKRtt8NHnfGrYrBomAgAF93dCAAEeY4IAABQUAgAdLQwA=
- Thread-topic: [PATCH v2 07/24] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration
Hello,
> >>>> +#ifdef CONFIG_DT_CPU_TOPOLOGY
> >>>> +extern struct cpu_topology cpu_topology[NR_CPUS];
> >>>
> >>> If at all possible, no new NR_CPUS dimensioned arrays please.
> >>
> >> This is also part of the code imported from Linux kernel 7.0, which is
> >> used to
> >> store
> >> unique topology data per CPU.
> >>
> >> I kept it as an array to match the original Linux source, but I understand
> >> the
> >> concern
> >> about adding new NR_CPUS dimensioned arrays in Xen. I can refactor it to
> use
> >> Xen's
> >> per-CPU infrastructure instead.
> >
> > Just a quick follow-up to my previous email:
> >
> > While I was looking into moving the topology data to a per-CPU variable,
> > I remembered the ongoing effort by the team working on CPU hotplug.
> >
> > This introduces a dilemma: during the early boot phase when we parse
> > the Device Tree topology, the per-CPU areas for CPUs that are not yet active
> > (or yet to be hotplugged) have not been allocated yet. Therefore, we
> > wouldn't
> > have a place to record the topology information for those inactive CPUs
> > at boot time.
> >
> > Should we have the hotplug team parse the Device Tree topology information
> > on-demand when a CPU is hot-plugged?
> >
> > Currently, the functions used to read the topology from the Device Tree are
> > marked with '__init'. Removing '__init' to keep these functions resident in
> > memory feels like a waste of memory.
>
> Indeed.
>
> > What do you think would be the best approach here?
>
> Can you know early enough how many CPUs there are going to be? If so,
> allocate the array just at the size needed. Next best option may be to
> have a NR_CPUS-dimensioned array in .init.data, for the used part then
> to be moved to a dynamically allocated, generally much smaller one.
Okay, I can use num_possible_cpus() for the size of the array.
Thank you,
Hirokazu Takahashi.
|
