On 2 March 2015 at 12:52, Srikar Dronamraju srikar@linux.vnet.ibm.com wrote:
- Vincent Guittot vincent.guittot@linaro.org [2015-02-27 16:54:13]:
Add the SD_PREFER_SIBLING flag for SMT level in order to ensure that the scheduler will put at least 1 task per core.
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Preeti U. Murthy preeti@linux.vnet.ibm.com
kernel/sched/core.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 29f7037..753f0a2 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6240,6 +6240,7 @@ sd_init(struct sched_domain_topology_level *tl, int cpu) */
if (sd->flags & SD_SHARE_CPUCAPACITY) {
sd->flags |= SD_PREFER_SIBLING; sd->imbalance_pct = 110; sd->smt_gain = 1178; /* ~15% */Prefer siblings logic dates back to https://lkml.org/lkml/2009/8/27/210 and only used in update_sd_lb_stats() where we have
if (child && child->flags & SD_PREFER_SIBLING) prefer_sibling = 1;
However what confuses me is why should we even look at a child domain's flag to balance tasks across the current sched domain? Why cant we just set and use a sd flag at current level than to look at child domain flag?
Peter, have you got some insight about the reason ?
egarding SMT, I see one advantage : the prefer sibling flag only need to be set if SMT is enable and a smt sched_domain is present but it implies some action at the parent level. If the flag was directly set at parent level, the behavior linked to SD_PREFER_SIBLING flag will be applied whatever the presence or not of the SMT domain.
Regards, Vincent
-- 1.9.1
-- 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/
-- Thanks and Regards Srikar Dronamraju