Re: [PATCH 2.6.12-rc4-mm2] perfctr: x86 update with K8 multicore fixes, take 2

[Mikael Pettersson <mikpe@csd.uu.se>]

Andi Kleen writes:
 > Mikael Pettersson <mikpe@csd.uu.se> writes:
 > 
 > > +#ifdef CONFIG_SMP
 > > +static void __init k8_multicore_init(void)
 > > +{
 > > +	cpumask_t non0cores;
 > > +	int i;
 > > +
 > > +	cpus_clear(non0cores);
 > > +	for(i = 0; i < NR_CPUS; ++i) {
 > > +		cpumask_t cores = cpu_core_map[i];
 > > +		int core0 = first_cpu(cores);
 > > +		if (core0 >= NR_CPUS)
 > > +			continue;
 > > +		cpu_clear(core0, cores);
 > > +		cpus_or(non0cores, non0cores, cores);
 > > +	}
 > > +	if (cpus_empty(non0cores))
 > > +		return;
 > > +	k8_is_multicore = 1;
 > 
 > That is still far too complicated. Just use current_cpu_data->x86_num_cores > 1 
 > That is simple enough that you don't need the ugly variable.

Right now you're right, but if you read the big comment just above
this code you'll see that once chips w/o the RevE erratum are
released, I'll make more serious use of the non0cores cpumask.
I consider _that_ the intended design (for the shared NB issue),
and the current code (just the k8_is_multicore flag) a workaround
for the NB clobber erratum in the 1st gen chips.

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