"Siddha, Suresh B" <[email protected]> wrote:
>
> On Tue, Jan 31, 2006 at 05:12:16PM -0800, Andrew Morton wrote:
> > It's still not clear what's supposed to be happening here.
> >
> > In build_sched_domains() we still have code which does:
> >
> >
> > for_each_cpu_mask(...) {
> > ...
> > #ifdef CONFIG_SCHED_MC
> > ...
> > #endif
> > #ifdef CONFIG_SCHED_SMT
> > ...
> > #endif
> > ...
> > }
> > ...
> > #ifdef CONFIG_SCHED_SMT
> > ...
> > #endif
> > ...
> > #ifdef CONFIG_SCHED_MC
> > ...
> > #endif
> >
> > So in the first case the SCHED_SMT code will win and in the second case the
> > SCHED_MC code will win. I think.
>
> I am not sure what you mean here. At all the above pointed places, both
> MC and SMT will win if both are configured.
I was assuming that the code really does something like:
#ifdef CONFIG_SCHED_MC
some_global_thing = <expr>
#endif
#ifdef CONFIG_SCHED_SMT
some_global_thing = <expr>
#endif
}
...
#ifdef CONFIG_SCHED_SMT
some_other_global_thing = <expr>
#endif
#ifdef CONFIG_SCHED_MC
some_other_global_thing = <expr>
#endif
Which, looking a bit closer, was wrong (yes?)
It is a bit irregular that in one place we do the SMT processing first and
in another we do the MC processing first, but I guess it'll work OK.
We do need to be super-careful in the reviewing and testing here. If we
slip up we won't have a nice crash to tell us. Instead we'll find that
some machines with some configs will, under some workloads, take a few
percent longer than they should. We could waste people's time for years
until some developer stumbles across something.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
