| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <96A765D7-7FD3-40EB-873B-0F9365569490@tencent.com>
Date: Thu, 23 Jul 2020 04:23:52 +0000
From: benbjiang(蒋彪) <benbjiang@...cent.com>
To: "Li, Aubrey" <aubrey.li@...ux.intel.com>
CC: Vineeth Remanan Pillai <vpillai@...italocean.com>,
Nishanth Aravamudan <naravamudan@...italocean.com>,
Julien Desfossez <jdesfossez@...italocean.com>,
Peter Zijlstra <peterz@...radead.org>,
"Tim Chen" <tim.c.chen@...ux.intel.com>,
"mingo@...nel.org" <mingo@...nel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"pjt@...gle.com" <pjt@...gle.com>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
Aubrey Li <aubrey.li@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"subhra.mazumdar@...cle.com" <subhra.mazumdar@...cle.com>,
"fweisbec@...il.com" <fweisbec@...il.com>,
"keescook@...omium.org" <keescook@...omium.org>,
"kerrnel@...gle.com" <kerrnel@...gle.com>,
Phil Auld <pauld@...hat.com>, Aaron Lu <aaron.lwe@...il.com>,
Aubrey Li <aubrey.intel@...il.com>,
Valentin Schneider <valentin.schneider@....com>,
Mel Gorman <mgorman@...hsingularity.net>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Joel Fernandes <joelaf@...gle.com>,
"joel@...lfernandes.org" <joel@...lfernandes.org>,
"vineethrp@...il.com" <vineethrp@...il.com>,
Chen Yu <yu.c.chen@...el.com>,
Christian Brauner <christian.brauner@...ntu.com>
Subject: Re: [RFC PATCH 11/16] sched: migration changes for core
scheduling(Internet mail)
Hi,
> On Jul 23, 2020, at 11:35 AM, Li, Aubrey <aubrey.li@...ux.intel.com> wrote:
>
> On 2020/7/23 10:42, benbjiang(蒋彪) wrote:
>> Hi,
>>
>>> On Jul 23, 2020, at 9:57 AM, Li, Aubrey <aubrey.li@...ux.intel.com> wrote:
>>>
>>> On 2020/7/22 22:32, benbjiang(蒋彪) wrote:
>>>> Hi,
>>>>
>>>>> On Jul 22, 2020, at 8:13 PM, Li, Aubrey <aubrey.li@...ux.intel.com> wrote:
>>>>>
>>>>> On 2020/7/22 16:54, benbjiang(蒋彪) wrote:
>>>>>> Hi, Aubrey,
>>>>>>
>>>>>>> On Jul 1, 2020, at 5:32 AM, Vineeth Remanan Pillai <vpillai@...italocean.com> wrote:
>>>>>>>
>>>>>>> From: Aubrey Li <aubrey.li@...el.com>
>>>>>>>
>>>>>>> - Don't migrate if there is a cookie mismatch
>>>>>>> Load balance tries to move task from busiest CPU to the
>>>>>>> destination CPU. When core scheduling is enabled, if the
>>>>>>> task's cookie does not match with the destination CPU's
>>>>>>> core cookie, this task will be skipped by this CPU. This
>>>>>>> mitigates the forced idle time on the destination CPU.
>>>>>>>
>>>>>>> - Select cookie matched idle CPU
>>>>>>> In the fast path of task wakeup, select the first cookie matched
>>>>>>> idle CPU instead of the first idle CPU.
>>>>>>>
>>>>>>> - Find cookie matched idlest CPU
>>>>>>> In the slow path of task wakeup, find the idlest CPU whose core
>>>>>>> cookie matches with task's cookie
>>>>>>>
>>>>>>> - Don't migrate task if cookie not match
>>>>>>> For the NUMA load balance, don't migrate task to the CPU whose
>>>>>>> core cookie does not match with task's cookie
>>>>>>>
>>>>>>> Signed-off-by: Aubrey Li <aubrey.li@...ux.intel.com>
>>>>>>> Signed-off-by: Tim Chen <tim.c.chen@...ux.intel.com>
>>>>>>> Signed-off-by: Vineeth Remanan Pillai <vpillai@...italocean.com>
>>>>>>> ---
>>>>>>> kernel/sched/fair.c | 64 ++++++++++++++++++++++++++++++++++++++++----
>>>>>>> kernel/sched/sched.h | 29 ++++++++++++++++++++
>>>>>>> 2 files changed, 88 insertions(+), 5 deletions(-)
>>>>>>>
>>>>>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>>>>>> index d16939766361..33dc4bf01817 100644
>>>>>>> --- a/kernel/sched/fair.c
>>>>>>> +++ b/kernel/sched/fair.c
>>>>>>> @@ -2051,6 +2051,15 @@ static void task_numa_find_cpu(struct task_numa_env *env,
>>>>>>> if (!cpumask_test_cpu(cpu, env->p->cpus_ptr))
>>>>>>> continue;
>>>>>>>
>>>>>>> +#ifdef CONFIG_SCHED_CORE
>>>>>>> + /*
>>>>>>> + * Skip this cpu if source task's cookie does not match
>>>>>>> + * with CPU's core cookie.
>>>>>>> + */
>>>>>>> + if (!sched_core_cookie_match(cpu_rq(cpu), env->p))
>>>>>>> + continue;
>>>>>>> +#endif
>>>>>>> +
>>>>>>> env->dst_cpu = cpu;
>>>>>>> if (task_numa_compare(env, taskimp, groupimp, maymove))
>>>>>>> break;
>>>>>>> @@ -5963,11 +5972,17 @@ find_idlest_group_cpu(struct sched_group *group, struct task_struct *p, int this
>>>>>>>
>>>>>>> /* Traverse only the allowed CPUs */
>>>>>>> for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) {
>>>>>>> + struct rq *rq = cpu_rq(i);
>>>>>>> +
>>>>>>> +#ifdef CONFIG_SCHED_CORE
>>>>>>> + if (!sched_core_cookie_match(rq, p))
>>>>>>> + continue;
>>>>>>> +#endif
>>>>>>> +
>>>>>>> if (sched_idle_cpu(i))
>>>>>>> return i;
>>>>>>>
>>>>>>> if (available_idle_cpu(i)) {
>>>>>>> - struct rq *rq = cpu_rq(i);
>>>>>>> struct cpuidle_state *idle = idle_get_state(rq);
>>>>>>> if (idle && idle->exit_latency < min_exit_latency) {
>>>>>>> /*
>>>>>>> @@ -6224,8 +6239,18 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t
>>>>>>> for_each_cpu_wrap(cpu, cpus, target) {
>>>>>>> if (!--nr)
>>>>>>> return -1;
>>>>>>> - if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
>>>>>>> - break;
>>>>>>> +
>>>>>>> + if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) {
>>>>>>> +#ifdef CONFIG_SCHED_CORE
>>>>>>> + /*
>>>>>>> + * If Core Scheduling is enabled, select this cpu
>>>>>>> + * only if the process cookie matches core cookie.
>>>>>>> + */
>>>>>>> + if (sched_core_enabled(cpu_rq(cpu)) &&
>>>>>>> + p->core_cookie == cpu_rq(cpu)->core->core_cookie)
>>>>>> Why not also add similar logic in select_idle_smt to reduce forced-idle? :)
>>>>> We hit select_idle_smt after we scaned the entire LLC domain for idle cores
>>>>> and idle cpus and failed,so IMHO, an idle smt is probably a good choice under
>>>>> this scenario.
>>>>
>>>> AFAIC, selecting idle sibling with unmatched cookie will cause unnecessary fored-idle, unfairness and latency, compared to choosing *target* cpu.
>>> Choosing target cpu could increase the runnable task number on the target runqueue, this
>>> could trigger busiest->nr_running > 1 logic and makes the idle sibling trying to pull but
>>> not success(due to cookie not match). Putting task to the idle sibling is relatively stable IMHO.
>>
>> I’m afraid that *unsuccessful* pullings between smts would not result in unstableness, because
>> the load-balance always do periodicly , and unsuccess means nothing happen.
> unsuccess pulling means more unnecessary overhead in load balance.
>
>> On the contrary, unmatched sibling tasks running concurrently could bring forced-idle to each other repeatedly,
>> Which is more unstable, and more costly when pick_next_task for all siblings.
> Not worse than two tasks ping-pong on the same target run queue I guess, and better if
> - task1(cookie A) is running on the target, and task2(cookie B) in the runqueue,
> - task3(cookie B) coming
>
> If task3 chooses target's sibling, it could have a chance to run concurrently with task2.
> But if task3 chooses target, it will wait for next pulling luck of load balancer
That’s more interesting. :)
Distributing different cookie tasks onto different cpus(or cpusets) could be the *ideal stable status* we want, as I understood.
Different cookie tasks running on sibling smts could hurt performance, and that should be avoided with best effort.
For above case, selecting idle sibling cpu can improve the concurrency indeed, but it decrease the imbalance for load-balancer.
In that case, load-balancer could not notice the imbalance, and would do nothing to improve the unmatched situation.
On the contrary, choosing the *target* cpu could enhance the imbalance, and load-balancer could try to pull unmatched task away,
which could improve the unmatched situation and be helpful to reach the *ideal stable status*. Maybe that’s what we expect. :)
Thx.
Regards,
Jiang
>
> Thanks,
> -Aubrey
>
>> In consideration of currently load-balance being not fully aware of core-scheduling, and can not improve
>> the *unmatched sibling* case, the *find_idlest_** entry should try its best to avoid the case, IMHO.
>
>> Also, just an advice and an option. :)
>>
>> Thx.
>> Regards,
>> Jiang
>>
>>>
>>>> Besides, choosing *target* cpu may be more cache friendly. So IMHO, *target* cpu may be a better choice if cookie not match, instead of idle sibling.
>>> I'm not sure if it's more cache friendly as the target is busy, and the coming task
>>> is a cookie unmatched task.
Powered by blists - more mailing lists