linux-kernel - Re: Active waiting with yield()

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: <Pine.LNX.4.64.0811181157260.13418@hs20-bc2-1.build.redhat.com>
Date:	Tue, 18 Nov 2008 12:11:23 -0500 (EST)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, rml@...h9.net,
	Alasdair G Kergon <agk@...hat.com>,
	Milan Broz <mbroz@...hat.com>
Subject: Re: Active waiting with yield()

On Tue, 18 Nov 2008, Alan Cox wrote:

> > You will touch the wait queue always when finishing the last pending 
> > request --- just to find out that there is no one waiting on it.
> 
> Why ? If my fast path for this something like
> 
> 	if (unlikely(foo->unload_pending) && count == 0)
> 		wake_up(..)
> 
> chances are that I can put unload_pending somewhere in a cache line with
> other stuff (certainly for L2) and it will get predicted well.

This makes a code branch that is very rarely tested and a potential bug. 
Every such rarely executed branch is a danger and even a silly typo in the 
code can hide there for many years without being noticed.

These rare branches are inevitable at some places, I just don't see a 
reason why make deliberately more of them.

> > And besides cache line, there is coding and testing overhead with wait 
> > queues.
> 
> If you want correctness you don't want busy waiting with yields - as Ingo
> pointed out already thats a bug in itself with hard realtime.

So, I say msleep(1) instead of yield(). What are the counterarguments to 
msleep?

> > So what are the reasons why you (and others) are against active waiting? 
> > All you are saying is that my reasons are wrong, but you haven't single 
> > example when active waiting causes trouble. If there is a workload when 
> 
> Untrue - I've given very clear reasons twice, and Ingo has given you
> more. If you don't wish to accept the answers that is your problem not
> mine, just expect such hacks to get a NAK and not make the kernel.

If it is only a matter of coding style and there is no valid reason why 
msleep(1) when unloading the driver would hurt. Just say it "we have this 
coding policy, we want the code to look like a state machine independent 
on the timer".

But don't invent pseudoreasons, such that: the system boots 30 seconds, 
shuts down in 5 seconds, and that 1ms-10ms sleep on shutdown is bad for 
virtualization and power consumption and performance and whatever --- even 
if it actually happens only to one user in a few years.

Mikulas

> Alan
> --
> "I can only provide the information, I can't make you hear it."
> 		- Shelley Bainter
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/