linux-kernel - Re: [PATCH] sched/fair: don't use waker's cpu if the waker of sync wake-up is interrupt

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: <9a6cadd9b65068b52c95adc44119bd09c6a4f9d7.camel@gmx.de>
Date:   Tue, 27 Apr 2021 06:21:30 +0200
From:   Mike Galbraith <efault@....de>
To:     Barry Song <song.bao.hua@...ilicon.com>,
        vincent.guittot@...aro.org, mingo@...hat.com, peterz@...radead.org,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de
Cc:     valentin.schneider@....com, juri.lelli@...hat.com,
        bristot@...hat.com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, xuwei5@...wei.com,
        prime.zeng@...ilicon.com, guodong.xu@...aro.org,
        yangyicong@...wei.com, liguozhu@...ilicon.com,
        linuxarm@...neuler.org, wanghuiqiang@...wei.com,
        Yongjia Xie <xieyongjia1@...wei.com>
Subject: Re: [PATCH] sched/fair: don't use waker's cpu if the waker of sync
 wake-up is interrupt

On Tue, 2021-04-27 at 14:37 +1200, Barry Song wrote:
>
> To fix this issue, this patch checks the waker of sync wake-up is a task
> but not an interrupt. In this case, the waker will schedule out and give
> CPU to wakee.

That rash "the waker will schedule out" assumption, ie this really
really is a synchronous wakeup, may be true in your particular case,
but the sync hint is so overused as to be fairly meaningless. We've
squabbled with it repeatedly over the years because of that.  It really
should either become more of a communication of intent than it
currently is, or just go away.

I'd argue for go away, simply because there is no way for the kernel to
know that there isn't more work directly behind any particular wakeup.

Take a pipe, does shoving some bits through a pipe mean you have no
further use of your CPU?  IFF you're doing nothing but playing ping-
pong, sure it does, but how many real proggies have zero overlap among
its threads of execution?  The mere notion of threaded apps having no
overlap *to be converted to throughput* is dainbramaged, which should
be the death knell of the sync wakeup hint.  Threaded apps can't do
stuff like, oh, networking, which uses the sync hint heavily, without
at least to some extent defeating the purpose of threading if we were
to take the hint seriously.  Heck, just look at the beauty (gak) of
wake_wide().  It was born specifically to combat the pure-evil side of
the sync wakeup hint.

Bah, 'nuff "Danger Will Robinson, that thing will *eat you*!!" ;-)

	-Mike