On 21 November 2014 at 13:37, Morten Rasmussen morten.rasmussen@arm.com wrote:
On Mon, Nov 03, 2014 at 04:54:45PM +0000, Vincent Guittot wrote:
[snip]
*/ if (prefer_sibling && sds->local &&
sds->local_stat.group_has_free_capacity)sgs->group_capacity_factor = min(sgs->group_capacity_factor, 1U);
group_has_capacity(env, &sds->local_stat) &&(sgs->sum_nr_running > 1)) {sgs->group_no_capacity = 1;sgs->group_type = group_overloaded;}I'm still a bit confused about SD_PREFER_SIBLING. What is the flag supposed to do and why?
The goal is to spread tasks across the group even if the the latter is not overloaded. for SMT level, the goal is to have 1 task per core before 1 task per HW thread
It looks like a weak load balancing bias attempting to consolidate tasks on domains with spare capacity. It does so by marking non-local groups as overloaded regardless of their actual load if the local group has spare capacity. Correct?
In patch 9 this behaviour is enabled for SMT level domains, which implies that tasks will be consolidated in MC groups, that is we prefer multiple tasks on sibling cpus (hw threads). I must be missing something essential. I was convinced that we wanted to avoid using sibling cpus on SMT systems as much as possible?
-- 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/