linux-kernel - Re: [PATCH 3/6] x86: Convert cpu_sibling_map to be a per cpu variable (v2) (fwd)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 04 Sep 2007 16:11:31 -0700
From:	Mike Travis <travis@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	clameter@....com, steiner@....com, ak@...e.de, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, kamalesh@...ux.vnet.ibm.com
Subject: Re: [PATCH 3/6] x86: Convert cpu_sibling_map to be a per cpu variable
 (v2) (fwd)



Andrew Morton wrote:
>> On Tue, 04 Sep 2007 13:29:11 -0700 Mike Travis <travis@....com> wrote:

>>> ---------- Forwarded message ----------
>>> Date: Fri, 31 Aug 2007 19:49:03 -0700
>>> From: Andrew Morton <akpm@...ux-foundation.org>
>>> To: travis@....com
>>> Cc: Andi Kleen <ak@...e.de>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
>>>     Christoph Lameter <clameter@....com>
>>> Subject: Re: [PATCH 3/6] x86: Convert cpu_sibling_map to be a per cpu variable
>>>     (v2)
>>>
>>> On Fri, 24 Aug 2007 15:26:57 -0700 travis@....com wrote:
>>>
>>>> Convert cpu_sibling_map from a static array sized by NR_CPUS to a
>>>> per_cpu variable.  This saves sizeof(cpumask_t) * NR unused cpus.
>>>> Access is mostly from startup and CPU HOTPLUG functions.
>>> ia64 allmodconfig:
>>>
>>> kernel/sched.c: In function `cpu_to_phys_group':                                                                             kernel/sched.c:5937: error: `per_cpu__cpu_sibling_map' undeclared (first use in this function)                               kernel/sched.c:5937: error: (Each undeclared identifier is reported only once
>>> kernel/sched.c:5937: error: for each function it appears in.)                                                                kernel/sched.c:5937: warning: type defaults to `int' in declaration of `type name'
>>> kernel/sched.c:5937: error: invalid type argument of `unary *'                                                               kernel/sched.c: In function `build_sched_domains':                                                                           kernel/sched.c:6172: error: `per_cpu__cpu_sibling_map' undeclared (first use in this function)                               kernel/sched.c:6172: warning: type defaults to `int' in declaration of `type name'                                           kernel/sched.c:6172: error: invalid type argument of `unary *'                                                               kernel/sched.c:6183: warning: type defaults to `int' in declaration of `type name'                                           kernel/sched.c:6183: error: invalid type argument of `unary *'                                                               
>> I'm thinking that the best approach would be to define a cpu_sibling_map() macro
>> to handle the cases where cpu_sibling_map is not a per_cpu variable?  Perhaps
>> something like:
>>
>> #ifdef CONFIG_SCHED_SMT
>> #ifndef cpu_sibling_map
>> #define cpu_sibling_map(cpu)    cpu_sibling_map[cpu]
>> #endif
>> #endif
>>
>> My question though, would include/linux/smp.h be the appropriate place for
>> the above define?  (That is, if the above approach is the correct one... ;-)
> 
> It'd be better to convert the unconverted architectures?

I can easily do the changes for ia64 and test them.  I don't have the capability
of testing on the powerpc.  

And are you asking for just the changes to fix the build problem, or the whole
set of the changes that were made for x86_64 and i386 in regards to converting
NR_CPU arrays to per cpu data?

Thanks,
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/