On Mon, Jun 09, 2014 at 06:56:17PM +0100, Dietmar Eggemann wrote: Thanks, Dietmar.
> I'm running these patches on my ARM TC2 on top of > kernel/git/torvalds/linux.git (v3.15-rc7-79-gfe45736f4134). There're > considerable changes in the area of sched domain setup since Vincent's > patchset 'rework sched_domain topology description' (destined for v3.16) > which you can find on kernel/git/tip/tip.git . > Yeah, PeterZ pointed it out. It was on top of mainline not tip. > Why did you make SD_WORKLOAD_CONSOLIDATION controllable via sysctl? All > the other SD flags are set during setup. > I don't understand. Any flag or parameter in sched_domain can be modified on-the-fly after booting via sysctl. The SD_XXX_INIT is a template to make the sched_domain initialization easier, IIUC. Yes, I should not unconditionally enable SD_WORKLOAD_CONSOLIDATION in MC and CPU domain (pointed out by PeterZ), but I did so for the purpose of testing this patchset at this moment. Eventually, this flag should not be turned on for any domain by default for many reasons, not to mention CPU topology is getting more diverse/complex. I just checked Vincent's "rework sched_domain topology description". The general picture for init sched_domain does not change. If you work on top of tip tree, you can simply skip this patch (0007), and after booting enable SD_WORKLOAD_CONSOLIDATION by: sysctl -w kernel.sched_domain.cpuX.domainY.flags += 0x8000 sysctl -w kernel.sched_domain.cpu0.domain1.consolidating_coeff=180 sysctl -w kernel.sched_cc_wakeup_threshold=80 > Your top_flag_domain() function > takes care of figuring out what is the highest sd level this is set on > during load-balance but I can't find any good reason to do it this way > other then for testing purposes? Any flag is used for testing whether it is set on or not when encountering it, including the flags in sched_domain for load balancing, this is why flag is called flag. My flag is any excpetion? Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/