[PATCH] export cpu_sibling_map

[PATCH] export cpu_sibling_map

[Stephane Eranian]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

Hello Tony,

For Montecito PMU support, I need to determine, in a kernel module, whether
or not threads are enabled. The only reliable way of doing this is to
compute the bit-weight of cpu_sibling_map[]. This symbol is exported on
x86 systems, but not on IA-64 so far. This patch exports the symbol.

Changelog:
	- export cpu_sibling_map[] to kernel modules

signed-off-by: stephane eranian <eranian@hpl.hp.com>

-- 
-Stephane

[-- Attachment #2: smp_sibling_map.diff --]
[-- Type: text/plain, Size: 390 bytes --]

diff --git a/arch/ia64/kernel/smpboot.c b/arch/ia64/kernel/smpboot.c
--- a/arch/ia64/kernel/smpboot.c
+++ b/arch/ia64/kernel/smpboot.c
@@ -139,6 +139,7 @@ EXPORT_SYMBOL(cpu_possible_map);
 
 cpumask_t cpu_core_map[NR_CPUS] __cacheline_aligned;
 cpumask_t cpu_sibling_map[NR_CPUS] __cacheline_aligned;
+EXPORT_SYMBOL(cpu_sibling_map);
 int smp_num_siblings = 1;
 int smp_num_cpucores = 1;
 

Re: [PATCH] export cpu_sibling_map

[Christoph Hellwig]

On Wed, Sep 20, 2006 at 12:53:47PM -0700, Stephane Eranian wrote:
> Hello Tony,
> 
> For Montecito PMU support, I need to determine, in a kernel module, whether
> or not threads are enabled. The only reliable way of doing this is to
> compute the bit-weight of cpu_sibling_map[]. This symbol is exported on
> x86 systems, but not on IA-64 so far. This patch exports the symbol.

Exporting global variables is a very bad thing, and we only do it if we
can't avoid it at all.  In this case it could be easily avoided by
exporting a nr_siblings_per_cpu() helper.

Re: [PATCH] export cpu_sibling_map

[Luck, Tony]

On Wed, Sep 20, 2006 at 09:23:25PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 20, 2006 at 12:53:47PM -0700, Stephane Eranian wrote:
> > Hello Tony,
> > 
> > For Montecito PMU support, I need to determine, in a kernel module, whether
> > or not threads are enabled. The only reliable way of doing this is to
> > compute the bit-weight of cpu_sibling_map[]. This symbol is exported on
> > x86 systems, but not on IA-64 so far. This patch exports the symbol.
> 
> Exporting global variables is a very bad thing, and we only do it if we
> can't avoid it at all.  In this case it could be easily avoided by
> exporting a nr_siblings_per_cpu() helper.

I also have my doubts about this in terms of hotplug cpu ... what
do you do if not all of the cpus have their siblings on-line?  The
question "Are threads enabled?" doesn't seem to have a simple yes/no
answer.  At best you might ask "Does cpu N have any online siblings?"
but the answer to that question could change before you could make
use of the information.

-Tony

Re: [PATCH] export cpu_sibling_map

[Stephane Eranian]

Tony,

On Wed, Sep 20, 2006 at 01:29:35PM -0700, Luck, Tony wrote:
> On Wed, Sep 20, 2006 at 09:23:25PM +0100, Christoph Hellwig wrote:
> > On Wed, Sep 20, 2006 at 12:53:47PM -0700, Stephane Eranian wrote:
> > > Hello Tony,
> > > 
> > > For Montecito PMU support, I need to determine, in a kernel module, whether
> > > or not threads are enabled. The only reliable way of doing this is to
> > > compute the bit-weight of cpu_sibling_map[]. This symbol is exported on
> > > x86 systems, but not on IA-64 so far. This patch exports the symbol.
> > 
> > Exporting global variables is a very bad thing, and we only do it if we
> > can't avoid it at all.  In this case it could be easily avoided by
> > exporting a nr_siblings_per_cpu() helper.
> 
> I also have my doubts about this in terms of hotplug cpu ... what
> do you do if not all of the cpus have their siblings on-line?  The
> question "Are threads enabled?" doesn't seem to have a simple yes/no
> answer.  At best you might ask "Does cpu N have any online siblings?"
> but the answer to that question could change before you could make
> use of the information.
> 

I think you bring up an interesting issue. because of HOTPLUG, I need to
register a cpu hotplug  notifier to make sure I get called to take
the appropriate action. As Christoph is suggesting, it is probably
best to hide the variable behind a helper function. Of course, there is
still a race between  the insertion of the module and a hotplug event.
Maybe there is a lock I could grab to serialize this?

This reminds me that I have a similar hotplug issue on P4.

Thanks

-- 
-Stephane