linux-kernel - Re: [PATCH] sched/fair: select waker's cpu for wakee on sync wakeup

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: <093acf40-9e57-d011-d90b-ea216700edc3@linux.alibaba.com>
Date:   Thu, 25 Aug 2022 14:45:05 +0800
From:   Peng Wang <rocking@...ux.alibaba.com>
To:     Mel Gorman <mgorman@...e.de>
Cc:     mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, bsegall@...gle.com, bristot@...hat.com,
        vschneid@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: select waker's cpu for wakee on sync wakeup

On 24/08/2022 16:46, , Mel Gorman wrote:
> On Wed, Aug 24, 2022 at 12:37:50PM +0800, Peng Wang wrote:
>> On sync wakeup, waker is about to sleep, and if it is the only
>> running task, wakee can get warm data on waker's cpu.
>>
>> Unixbench, schbench, and hackbench are tested on
>> Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz (192 logic CPUs)
>>
>> Unixbench get +20.7% improvement with full threads mainly
>> because of the pipe-based context switch and fork test.
>>
>> No obvious impact on schbench.
>>
>> This change harms hackbench with lower concurrency, while gets improvement
>> when concurrency increases.
>>
> 
> Note that historically patches in this direction have been hazardous because
> it makes a key assumption "sync wakers always go to sleep in the near future"
> when the sync hint is not that reliable. Networking from a brief glance
> still uses sync wakeups where wakers could have a 1:N relationship between
> work producers and work consumers that would then stack multiple tasks on
> one CPU for multiple consumers. The workloads mentioned in the changelog
> are mostly strictly-synchronous wakeups (i.e. the waker definitely goes
> to sleep almost immediately) and benefit from this sort of patch but it's
> not necessarily a universal benefit.

Hi, Mel

Thanks for your clarification.

Besides these benchmarks, I also find a similar strictly-synchronous 
wakeup case [1].

[1]https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1478754.html

> 
> Note that most of these hazards occurred *LONG* before I was paying much
> attention to how the scheduler behaved so I cannot state "sync is still
> unreliable" with absolute certainty. However, long ago there was logic
> that tried to track the accuracy of the sync hint that was ultimately
> abandoned by commit e12f31d3e5d3 ("sched: Remove avg_overlap"). AFAIK,
> the sync hint is still not 100% reliable and while stacking sync works
> for some workloads, it's likely to be a regression magnet for network
> intensive workloads or client/server workloads like databases where
> "synchronous wakeups are not always synchronous".
>
Yes, you are right. Perhaps in such situation, a strong contract from 
user is a better alternative than struggling with the weak hint in kernel.