On 21 November 2014 at 13:37, Morten Rasmussen [off-list ref] wrote:

On Mon, Nov 03, 2014 at 04:54:45PM +0000, Vincent Guittot wrote:

[snip]

quoted

                 */
                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 at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/