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.
> The code is so repetitive in there that
> `patch' may have put the hunks in the wrong place.
I will check your -mm tree.
>
> What is the design intention here? What do we _want_ to happen if both MC
> and SMT are enabled?
If both MC and SMT are enabled(and available on the system), then there will
be two domain levels one for MC and another one for SMT.
> Also the path tests CONFIG_SCHED_MT in a few places where it meant to use
> CONFIG_SCHED_SMT, which rather casts doubt upon the testing quality.
:( Got introduced in my last version of the patch. Thanks for fixing it.
suresh
-
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]
