Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-26 Thread Ingo Molnar
* H. Peter Anvin wrote: > I strongly disagree with putting variables in file scope when > function scope will do, [...] Yes, you are right that single-use file scope statics 'could' be moved function local and are syntactically superior because in that case other functions cannot make use of

Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-26 Thread Prarit Bhargava
On 01/26/2014 03:29 PM, H. Peter Anvin wrote: > I strongly disagree with putting variables in file scope when function scope > will do, but I do like to see static variables before automatics. Anyway, > this is bikeshedding. > > Ingo Molnar wrote: >> >> * H. Peter Anvin wrote: >> >>> s/glob

Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-26 Thread H. Peter Anvin
I strongly disagree with putting variables in file scope when function scope will do, but I do like to see static variables before automatics. Anyway, this is bikeshedding. Ingo Molnar wrote: > >* H. Peter Anvin wrote: > >> s/global/static/, with a big loud comment why it is okay. > >It would

Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-26 Thread Ingo Molnar
* H. Peter Anvin wrote: > s/global/static/, with a big loud comment why it is okay. It would be a global no matter which form we use, but for maintainability reasons I generally prefer a static put right before the function that uses it: static cpumask_t mask; static func(..

Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-26 Thread H. Peter Anvin
s/global/static/, with a big loud comment why it is okay. Ingo Molnar wrote: > >* Prarit Bhargava wrote: > >> >> >> On 01/26/2014 08:32 AM, Ingo Molnar wrote: >> > >> > * Prarit Bhargava wrote: >> > >> >> On 01/25/2014 03:02 AM, Ingo Molnar wrote: >> >>> >> >>> * Yinghai Lu wrote: >> >>> >

Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-26 Thread Ingo Molnar
* Prarit Bhargava wrote: > > > On 01/26/2014 08:32 AM, Ingo Molnar wrote: > > > > * Prarit Bhargava wrote: > > > >> On 01/25/2014 03:02 AM, Ingo Molnar wrote: > >>> > >>> * Yinghai Lu wrote: > >>> > Fix warning: > arch/x86/kernel/irq.c: In function check_irq_vectors_for_cpu_disab

Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-26 Thread Prarit Bhargava
On 01/26/2014 08:32 AM, Ingo Molnar wrote: > > * Prarit Bhargava wrote: > >> On 01/25/2014 03:02 AM, Ingo Molnar wrote: >>> >>> * Yinghai Lu wrote: >>> Fix warning: arch/x86/kernel/irq.c: In function check_irq_vectors_for_cpu_disable: arch/x86/kernel/irq.c:337:1: warning: the f

Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-26 Thread Ingo Molnar
* Prarit Bhargava wrote: > On 01/25/2014 03:02 AM, Ingo Molnar wrote: > > > > * Yinghai Lu wrote: > > > >> Fix warning: > >> arch/x86/kernel/irq.c: In function check_irq_vectors_for_cpu_disable: > >> arch/x86/kernel/irq.c:337:1: warning: the frame size of 2052 bytes is > >> larger than 2048

Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-26 Thread Prarit Bhargava
On 01/25/2014 03:02 AM, Ingo Molnar wrote: > > * Yinghai Lu wrote: > >> Fix warning: >> arch/x86/kernel/irq.c: In function check_irq_vectors_for_cpu_disable: >> arch/x86/kernel/irq.c:337:1: warning: the frame size of 2052 bytes is larger >> than 2048 bytes >> >> when NR_CPUS=8192 >> >> We sho

Re: [PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-25 Thread Ingo Molnar
* Yinghai Lu wrote: > Fix warning: > arch/x86/kernel/irq.c: In function check_irq_vectors_for_cpu_disable: > arch/x86/kernel/irq.c:337:1: warning: the frame size of 2052 bytes is larger > than 2048 bytes > > when NR_CPUS=8192 > > We should use zalloc_cpumask_var() instead. > > -v2: update to

[PATCH -v2] x86: allocate cpumask during check irq vectors

2014-01-24 Thread Yinghai Lu
Fix warning: arch/x86/kernel/irq.c: In function check_irq_vectors_for_cpu_disable: arch/x86/kernel/irq.c:337:1: warning: the frame size of 2052 bytes is larger than 2048 bytes when NR_CPUS=8192 We should use zalloc_cpumask_var() instead. -v2: update to GFP_ATOMIC instead and free the allocated