linux-kernel - Re: [PATCH 2/3] sched,fair: Fix local starvation

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 22 May 2016 16:24:49 +0800
From:	Wanpeng Li <kernellwp@...il.com>
To:	Mike Galbraith <mgalbraith@...e.de>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Pavan Kondeti <pkondeti@...eaurora.org>,
	Ben Segall <bsegall@...gle.com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Morten Rasmussen <morten.rasmussen@....com>,
	Paul Turner <pjt@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Byungchul Park <byungchul.park@....com>,
	Andrew Hunter <ahh@...gle.com>
Subject: Re: [PATCH 2/3] sched,fair: Fix local starvation

2016-05-22 16:04 GMT+08:00 Mike Galbraith <mgalbraith@...e.de>:
> On Sun, 2016-05-22 at 15:42 +0800, Wanpeng Li wrote:
>> 2016-05-22 15:32 GMT+08:00 Mike Galbraith <mgalbraith@...e.de>:
>> > On Sun, 2016-05-22 at 15:27 +0800, Wanpeng Li wrote:
>> >
>> > > What's the meaning of 'x-cpu wakeup'? ;-)
>> >
>> > Generally, cross CPU, as in waker/wakee reside on different CPUs,
>> > but
>> > in this case, it's cross socket wakeup.
>>
>> Do you mean wakeup wakees on remote socket don't imply
>> migration/normalized, why?
>
> Because the wakee is NOT necessarily migrated simply because it lives
> in some remote cache domain.  It was a simple but nasty booboo.
>
> ttwu():
>         cpu = select_task_rq(p, p->wake_cpu, SD_BALANCE_WAKE, wake_flags);
>         if (task_cpu(p) != cpu) {
>                 wake_flags |= WF_MIGRATED;
>                 set_task_cpu(p, cpu);
>
> set_task_cpu():
>                 if (task_cpu(p) != new_cpu) {
>                 if (p->sched_class->migrate_task_rq)
>                         p->sched_class->migrate_task_rq(p);
>                                         ^^^^^^^^^^^^^^^^^^
>
> migrate_task_rq_fair() normalizes wakee, those wakees that did not
> migrate have NOT been normalized, leaving two flavors of wakee on the
> wake_list, with no discriminator.  Store class information internally,
> and the x-socket information disconnect evaporates.

Do all wakees live on some remote cache domain will not migrate or
just the ones which can't find an suitable cpu in current local
socket(failed in select_task_rq())?

Regards,
Wanpeng Li