linux-kernel - Re: sched: wakeup setting TIF_NEED

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 for Android: free password hash cracker in your pocket

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

Message-ID: <YIkdDeb9c+XmDRvM@hirez.programming.kicks-ass.net>
Date:   Wed, 28 Apr 2021 10:30:05 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Jörn Engel <joern@...estorage.com>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>
Subject: Re: sched: wakeup setting TIF_NEED_RESCHED too frequently

On Tue, Apr 27, 2021 at 02:16:50PM -0700, Jörn Engel wrote:
> Anyway, trying to find a cause, I noticed the following call chain:
> 	set_nr_if_polling()
> 	ttwu_queue_remote()
> 	ttwu_queue()
> 	try_to_wake_up()
> 	default_wake_function()
> 	curr->func()
> 	__wake_up_common()
> 	__wake_up_common_lock()
> 	__wake_up()
> 	wake_up()
> 
> Call chain above is manually created from source code.  Closest sample I
> caught with instrumentation is missing the leaf calls after
> try_to_wake_up():
> 	_raw_spin_unlock_irqrestore+0x1f/0x40
> 	try_to_wake_up+0x425/0x5e0
> 	wake_up_q+0x3f/0x80
> 	futex_wake+0x159/0x180
> 	do_futex+0xcd/0xba0
> 
> Afaics, the result is us setting TIF_NEED_RESCHED on any wakeup, unless
> wake_list is already populated.  Is that actually intentional?  And is
> that useful for performance of latency?  I think it isn't, but I am
> probably missing something here.

set_nr_if_polling() only sets TIF_NEED_RESCHED IFF TIF_POLLING_NRFLAG is
set. TIF_POLLING_NRFLAG is only set when idle and is then sufficient to
wake that cpu and reschedule.

If not TIF_POLLING_NRFLAG, then we send an IPI to deal with the
non-empty wake_list.