Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1658160

Re: [PATCH] arch/sparc: support NR_CPUS = 4096

From jane.chu@oracle.com
Newsgroups linux.kernel
Subject Re: [PATCH] arch/sparc: support NR_CPUS = 4096
Date 2017-06-05 23:40 +0200
Message-ID <tP7Tc-8dq-11@gated-at.bofh.it> (permalink)
References <tNFYZ-8b0-1@gated-at.bofh.it> <tONrr-3lC-9@gated-at.bofh.it>
Organization Oracle Corporation

Show all headers | View raw


Hi,

I have a question about a checkpatch.pl warning against the

use of NR_CPUS -

$ ./scripts/checkpatch.pl diff.patch
WARNING: usage of NR_CPUS is often wrong - consider using 
cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc
#14: FILE: arch/sparc/kernel/irq_64.c:1039:
+       BUILD_BUG_ON((NR_CPUS * sizeof(u16)) > PAGE_SIZE);

num_possible_cpus() is the hard limit on a domain without platform reboot,

it is capped by both NR_CPUS and 'max_cpus' (a platform property in the

machine description).  So it is theoretically possible to have NR_CPUS>4096

but num_possible_cpus() < 4096 -- a scenario I think we'd prefer to reject.

Is it okay to ignore the checkpatch.pl warning in this case?

thanks,

-jane


On 06/04/2017 04:46 PM, David Miller wrote:
> From: Jane Chu <jane.chu@oracle.com>
> Date: Thu,  1 Jun 2017 15:39:13 -0600
>
>> diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
>> index 4d0248a..5b19108 100644
>> --- a/arch/sparc/kernel/irq_64.c
>> +++ b/arch/sparc/kernel/irq_64.c
>> @@ -1034,12 +1034,12 @@ static void __init init_cpu_send_mondo_info(struct trap_per_cpu *tb)
>>   {
>>   #ifdef CONFIG_SMP
>>   	unsigned long page;
>> +	unsigned int order;
>>   
>> -	BUILD_BUG_ON((NR_CPUS * sizeof(u16)) > (PAGE_SIZE - 64));
>> -
>> -	page = get_zeroed_page(GFP_KERNEL);
>> +	order = get_order(num_possible_cpus() * sizeof(u16) + 64);
>> +	page = __get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
>>   	if (!page) {
> The only reason we allocated these two items together was because it
> was convenient and it all fit into a single page.
>
> Since it now doesn't, it makes sense to split it up.
>
> Simply use a single page for the cpu_list_pa and kzalloc for the
> cpu_mondo_block.
>
> This also allows to keep the BUILD_BUG_ON(), which I really wish
> you hadn't tried to remove.
>
> static void __init init_cpu_send_mondo_info(struct trap_per_cpu *tb)
> {
> #ifdef CONFIG_SMP
> 	unsigned long page;
> 	void *mondo;
>
> 	BUILD_BUG_ON((NR_CPUS * sizeof(u16)) > PAGE_SIZE);
>
> 	mondo = kzalloc(64, GFP_KERNEL);
> 	if (!mondo) {
> 		prom_printf("SUN4V: Error, cannot allocate mondo block.\n");
> 		prom_halt();
> 	}
> 	tb->cpu_mondo_block_pa = __pa(mondo);
>
> 	page = get_zeroed_page(GFP_KERNEL);
> 	if (!page) {
> 		prom_printf("SUN4V: Error, cannot allocate cpu list page.\n");
> 		prom_halt();
> 	}
> 	tb->cpu_list_pa = __pa(page);
> #endif
> }
>
> Thanks.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] arch/sparc: support NR_CPUS = 4096 Jane Chu <jane.chu@oracle.com> - 2017-06-01 23:40 +0200
  Re: [PATCH] arch/sparc: support NR_CPUS = 4096 David Miller <davem@davemloft.net> - 2017-06-05 01:50 +0200
    Re: [PATCH] arch/sparc: support NR_CPUS = 4096 jane.chu@oracle.com - 2017-06-05 21:20 +0200
    Re: [PATCH] arch/sparc: support NR_CPUS = 4096 jane.chu@oracle.com - 2017-06-05 23:40 +0200
      Re: [PATCH] arch/sparc: support NR_CPUS = 4096 David Miller <davem@davemloft.net> - 2017-06-06 00:00 +0200

csiph-web