Re: [Patch] sched: new sched domain for representing multi-core

["Siddha, Suresh B" <suresh.b.siddha@intel.com>]

On Fri, Jan 27, 2006 at 05:42:11AM +0100, Andi Kleen wrote:
> On Thursday 26 January 2006 10:51, Siddha, Suresh B wrote:
> 
> With this patch does the new distance checking code in the scheduler 
> from Ingo automatically discover all the relevant distances?

Yes.

> 
> > +#ifdef CONFIG_SMP
> > +	unsigned int cpu = (c == &boot_cpu_data) ? 0 : (c - cpu_data);
> > +#endif
> 
> Wouldn't it be better to just put that information into the cpuinfo_x86?
> We're having too many per CPU arrays already.


> Actually it would be better to pass this information in some other way
> to smpboot.c than to add more and more arrays like this.  It's only
> needed for the current CPU, because for the others the information
> is in cpu_llc_shared_map

In smpboot.c we require the llc id of current CPU and all other online cpus.
I will put cpu_llc_shared_map info into cpuinfo_x86 (in future with power
savings sched policy, it will be used whenever someone changes sched policy)
And will make cpu_llc_id[] as __cpuinitdata.

> 
> Perhaps SMP boot up should pass around a pointer to temporary data like this?
> Or discover it in smpboot.c with a function call?
> 
> > -#ifdef CONFIG_SCHED_SMT
> > +#if defined(CONFIG_SCHED_SMT)
> >  		sd = &per_cpu(cpu_domains, i);
> > +#elif defined(CONFIG_SCHED_MC)
> 
> elif? What happens where there are both shared caches and SMT? 

Lowest domain the cpu gets attached to it is SMT domain.

thanks,
suresh
-
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/