linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Hari Bathini <hbathini@linux.ibm.com>
To: Pingfan Liu <piliu@redhat.com>
Cc: Baoquan He <bhe@redhat.com>,
	kexec@lists.infradead.org,
	Mahesh Salgaonkar <mahesh@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Ming Lei <ming.lei@redhat.com>,
	Wen Xiong <wenxiong@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCHv8 3/5] powerpc/setup: Handle the case when boot_cpuid greater than nr_cpus
Date: Thu, 12 Oct 2023 11:02:20 +0530	[thread overview]
Message-ID: <fb374fcc-487b-cb6c-6aa6-76fb49eee99a@linux.ibm.com> (raw)
In-Reply-To: <ZSYQ9odHpQDWN5ca@piliu.users.ipa.redhat.com>



On 11/10/23 8:35 am, Pingfan Liu wrote:
> On Tue, Oct 10, 2023 at 01:56:13PM +0530, Hari Bathini wrote:
>>
>>
>> On 09/10/23 5:00 pm, Pingfan Liu wrote:
>>> If the boot_cpuid is smaller than nr_cpus, it requires extra effort to
>>> ensure the boot_cpu is in cpu_present_mask. This can be achieved by
>>> reserving the last quota for the boot cpu.
>>>
>>> Note: the restriction on nr_cpus will be lifted with more effort in the
>>> successive patches
>>>
>>> Signed-off-by: Pingfan Liu <piliu@redhat.com>
>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>> Cc: Nicholas Piggin <npiggin@gmail.com>
>>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>>> Cc: Wen Xiong <wenxiong@linux.ibm.com>
>>> Cc: Baoquan He <bhe@redhat.com>
>>> Cc: Ming Lei <ming.lei@redhat.com>
>>> Cc: kexec@lists.infradead.org
>>> To: linuxppc-dev@lists.ozlabs.org
>>> ---
>>>    arch/powerpc/kernel/setup-common.c | 25 ++++++++++++++++++++++---
>>>    1 file changed, 22 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
>>> index 81291e13dec0..f9ef0a2666b0 100644
>>> --- a/arch/powerpc/kernel/setup-common.c
>>> +++ b/arch/powerpc/kernel/setup-common.c
>>> @@ -454,8 +454,8 @@ struct interrupt_server_node {
>>>    void __init smp_setup_cpu_maps(void)
>>>    {
>>>    	struct device_node *dn;
>>> -	int shift = 0, cpu = 0;
>>> -	int j, nthreads = 1;
>>> +	int terminate, shift = 0, cpu = 0;
>>> +	int j, bt_thread = 0, nthreads = 1;
>>>    	int len;
>>>    	struct interrupt_server_node *intserv_node, *n;
>>>    	struct list_head *bt_node, head;
>>> @@ -518,6 +518,7 @@ void __init smp_setup_cpu_maps(void)
>>>    			for (j = 0 ; j < nthreads; j++) {
>>>    				if (be32_to_cpu(intserv[j]) == boot_cpu_hwid) {
>>>    					bt_node = &intserv_node->node;
>>> +					bt_thread = j;
>>>    					found_boot_cpu = true;
>>>    					/*
>>>    					 * Record the round-shift between dt
>>> @@ -537,11 +538,21 @@ void __init smp_setup_cpu_maps(void)
>>>    	/* Select the primary thread, the boot cpu's slibing, as the logic 0 */
>>>    	list_add_tail(&head, bt_node);
>>>    	pr_info("the round shift between dt seq and the cpu logic number: %d\n", shift);
>>> +	terminate = nr_cpu_ids;
>>>    	list_for_each_entry(intserv_node, &head, node) {
>>> +		j = 0;
>>
>>> +		/* Choose a start point to cover the boot cpu */
>>> +		if (nr_cpu_ids - 1 < bt_thread) {
>>> +			/*
>>> +			 * The processor core puts assumption on the thread id,
>>> +			 * not to breach the assumption.
>>> +			 */
>>> +			terminate = nr_cpu_ids - 1;
>>
>> nthreads is anyway assumed to be same for all cores. So, enforcing
>> nr_cpu_ids to a minimum of nthreads (and multiple of nthreads) should
>> make the code much simpler without the need for above check and the
>> other complexities addressed in the subsequent patches...
>>
> 
> Indeed, this series can be splited into two partsk, [1-2/5] and [3-5/5].
> In [1-2/5], if smaller, the nr_cpu_ids is enforced to be equal to
> nthreads. I will make it align upward on nthreads in the next version.
> So [1-2/5] can be totally independent from the rest patches in this
> series.

Yup. Would prefer it that way.

>  From an engineer's perspective, [3-5/5] are added to maintain the
> nr_cpus semantics. (Finally, nr_cpus=1 can be achieved but requiring
> effort on other subsystem)

I understand it would be nice to maintain semantics but not worth the
complexity it brings, IMHO. So, my suggest would be to drop [3-5/5].

Thanks
Hari

  reply	other threads:[~2023-10-12  5:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-09 11:30 [PATCHv8 0/5] enable nr_cpus for powerpc Pingfan Liu
2023-10-09 11:30 ` [PATCHv8 1/5] powerpc/setup : Enable boot_cpu_hwid for PPC32 Pingfan Liu
2023-10-10  4:44   ` Sourabh Jain
2023-10-10  8:24     ` Sourabh Jain
2023-10-10  9:08     ` Sourabh Jain
2023-10-11  2:30       ` Pingfan Liu
2023-10-11 10:53         ` Sourabh Jain
2023-10-12 13:20           ` Pingfan Liu
2023-10-16  6:43             ` Sourabh Jain
2023-10-17  2:12               ` Pingfan Liu
2023-10-09 11:30 ` [PATCHv8 2/5] powerpc/setup: Loosen the mapping between cpu logical id and its seq in dt Pingfan Liu
2023-10-10 10:37   ` Hari Bathini
2023-10-11  3:11     ` Pingfan Liu
2023-10-09 11:30 ` [PATCHv8 3/5] powerpc/setup: Handle the case when boot_cpuid greater than nr_cpus Pingfan Liu
2023-10-10  8:26   ` Hari Bathini
2023-10-11  3:05     ` Pingfan Liu
2023-10-12  5:32       ` Hari Bathini [this message]
2023-10-09 11:30 ` [PATCHv8 4/5] powerpc/cpu: Skip impossible cpu during iteration on a core Pingfan Liu
2023-10-09 11:30 ` [PATCHv8 5/5] powerpc/setup: alloc extra paca_ptrs to hold boot_cpuid Pingfan Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fb374fcc-487b-cb6c-6aa6-76fb49eee99a@linux.ibm.com \
    --to=hbathini@linux.ibm.com \
    --cc=bhe@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mahesh@linux.ibm.com \
    --cc=ming.lei@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=piliu@redhat.com \
    --cc=wenxiong@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).