linux-kernel - Re: [RFC PATCH] sched/fair: Introduce SIS_PAIR to wakeup task on local idle core first

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]

Message-ID: <795a6d9475ecb444d219a9d36dc93b48a69e960e.camel@gmx.de>
Date:   Tue, 16 May 2023 13:51:26 +0200
From:   Mike Galbraith <efault@....de>
To:     Chen Yu <yu.c.chen@...el.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Tim Chen <tim.c.chen@...el.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        K Prateek Nayak <kprateek.nayak@....com>,
        Abel Wu <wuyun.abel@...edance.com>,
        Yicong Yang <yangyicong@...ilicon.com>,
        "Gautham R . Shenoy" <gautham.shenoy@....com>,
        Len Brown <len.brown@...el.com>,
        Chen Yu <yu.chen.surf@...il.com>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>,
        Aaron Lu <aaron.lu@...el.com>, Barry Song <baohua@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] sched/fair: Introduce SIS_PAIR to wakeup task on
 local idle core first

On Tue, 2023-05-16 at 16:41 +0800, Chen Yu wrote:
> >
> IMO this issue could be generic, the cost of C2C is O(sqrt (n)), in theory on
> a system with a large number of LLC and with SMT enabled, the issue is easy to
> be detected.
>
> As an example, I did not choose a super big system,
> but a desktop i9-10980XE, launches 2 pairs of ping-ping tasks.
>
> Each pair of tasks are bound to 1 dedicated core:
> ./context_switch1_processes -s 30 -t 2
> average:956883
>
> No CPU affinity for the tasks:
> ./context_switch1_processes -s 30 -t 2 -n
> average:849209
>
> We can see that, waking up the wakee on local core brings benefits on this platform.

Sure, tiny ping-pong balls fly really fast in a shared L2 siblings. The
players being truly synchronous, there's not a whole lot of room for
resource competition, and they do about as close to nothing but
schedule as you can get.

That's not a workload, much less one worthy of special consideration.
It is a useful tool though, exposed a big socket issue, good job tool.
Changing task placement strategy in response to that issue makes zero
sense to me.  There are many ways to schedule and wake other tasks at
high frequency, all use the same paths.  Reduce the pain that big box
sees when playing high speed ping-pong, and real workloads will profit
in boxen large and small.  More in large than small, but nobody loses,
everybody wins.

	-Mike
>