Re: [RFC PATCH 07/16 v3] Init Workload Consolidation flags in sched_domain

[Dietmar Eggemann <dietmar.eggemann@arm.com>]

On 10/06/14 19:09, Yuyang Du wrote:
> On Tue, Jun 10, 2014 at 12:52:06PM +0100, Dietmar Eggemann wrote:
> 
> Hi Dietmar,
> 
>> Not in this sense but there is no functionality in the scheduler right
>> now to check constantly if an sd flag has been set/unset via sysctl.
> 
> Sorry, I still don't understand. There are many "if (sd->flags & SD_XXX)"
> in fair.c. What does it mean to you?
> 
> Probably you mean the SD_XX should be fixed in init and never changed via sysctl
> thereafter. Ah... I don't know about this...

yes :-) I'm referring to your top_flag_domain() function which you need
to check what the highest sd level is where your flag is set. Existing
code only relies on flag setup during startup and after cpu hotplug or
on cached per-cpu sd pointers like sd_llc .

> 
> Overall, I think I should come up with a better way to implement the SD_WORKLOAD_CONSOLIDATION
> policy (enabled or disabled) in load balancing (as is also pointed out by PeterZ).
> But I just don't see the current implementation is any particular different than
> any other SD_XX's.
> 
> Have you tried it on your platform?

I'm running these patches on my ARM TC2 (2 clusters (2 CPUs, 3 CPUs)) on
top of kernel/git/torvalds/linux.git (v3.15-rc7-79-gfe45736f4134). By
default, on this platform CC is enabled on MC and CPU level. Overall
workloads show very different behaviour (CC enabled on MC and CPU level
as well as only enabled on MC level) compared to testruns wo/ CC but I
do not have the time to analyse it further. BTW, I hot-plugged out the
3rd CPU on the 2. cluster (there is this comment on top of
__nonshielded_groups() 'every sched_group has the same weight').

-- Dietmar

> 
> Thanks a lot,
> Yuyang
>