Re: [RFC 5/6] Improvise cgroup interface for classifying jitter from WOF tasks

[Parth Shah <parth015@linux.vnet.ibm.com>]

On 4/12/19 6:38 PM, Dietmar Eggemann wrote:
> On 3/22/19 7:06 AM, Parth Shah wrote:
> 
> [...]
> 
>> @@ -6236,7 +6259,15 @@ static int select_non_idle_core(struct task_struct *p, int prev_cpu)
>>       struct cpumask *cpus = &highutil_task_mask_copy;
>>       int core, smt;
>>   -    cpumask_copy(cpus, highutil_task_cpu_mask);
>> +    /*
>> +     * Prefer jitters to be pulled on core occupying WOF tasks
>> +     * If such tasks are not running then use long code path to find
>> +     * non-idle core with spare capacity
>> +     */
> 
> I'm struggling to grasp what you mean by ' ... long code path to find non-idle core with spare capacity' here?
> 
> We're here in:
> select_task_rq_fair()->__select_idle_sibling()->select_non_idle_core()
> 
> What is the 'long code path'? In case select_non_idle_core() can't find a CPU, select_idle_sibling() is called but IMHO that's the original fastpath operating on the LLC domain.
> 
> It can't be the slow path find_idlest_cpu() because that's only called in case __select_idle_sibling() isn't called.
> 
> [...]
> 

Maybe the comment is not self-explainable. Please follow a below one,

Here we have two cpumask to iterate through
1. wof_tasks_cpu_mask which contains CPU occupied by user classified task and is hence easier to track
2. highutil_task_cpu_mask which contains CPU which are non-idle (not core_underutilized)

So, the selection of "cpus" can be either from the above two masks. 
Selecting "wof_tasks_cpu_mask" leads to quicker and better selection of non idle CPU,
whereas "highutil_task_cpu_mask" will contain more CPUs (inclusive of wof_tasks_cpu_mask) and hence finding perfect CPU may require more iterations.

Hence, selecting "highutil_task_cpu_mask" is relatively exhaustive (which I termed "longer code path") in general cases.

Hope this helps.

Thanks