Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1397069
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC] sched: low latency feedback to userspace |
| Date | 2016-05-09 15:50 +0200 |
| Message-ID | <rwTJn-6CD-1@gated-at.bofh.it> (permalink) |
| References | <rwQsa-3re-3@gated-at.bofh.it> <rwRoe-4pL-7@gated-at.bofh.it> <rwT6H-6j0-29@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, May 09, 2016 at 03:03:59PM +0200, Maximilian Krüger wrote: > > >sched_yield() for anything other than SCHED_FIFO / SCHED_DEADLINE is a > >'bug'. That is, calling sched_yield() outside of those two cases is > >undefined behaviour and the kernel is free to eat your granny and set your > >pet on fire. > > okay, fair.c/yield_task_fair() does not exactly sound, as if it would set my > granny on fire or eat my pet, nor does man 2 yield, but correct me if I'm > wrong. So barring the co-operative multitasking model (which is still somewhat employed in places), sched_yield() is basically undefined except for FIFO / DEADLINE. Now, every OS does 'something', and we do too. But that something could really include anything from nothing to setting pet on fire. That said; there is a lot of crufty code out there that calls sched_yield() for all sorts of reasons, but mostly bad ones. I have seen code like: while (!event) sched_yield(); to wait for completion of 'event'. Now imagine what would happen if this code ends up running at a real-time priority? And, no, you really cannot say that will never happen as an application developer, because the application user might start you with a different scheduling class (for whatever reason), or the system might have unconditional priority inheritance and you get caught in a boost chain, or whatever. The worst part is; we've had people reject patches when we fixed their yield abuse for them :/
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[RFC] sched: low latency feedback to userspace Maximilian Krüger <maximilian.krueger@fau.de> - 2016-05-09 12:20 +0200
Re: [RFC] sched: low latency feedback to userspace Peter Zijlstra <peterz@infradead.org> - 2016-05-09 13:20 +0200
Re: [RFC] sched: low latency feedback to userspace Maximilian Krüger <maximilian.krueger@fau.de> - 2016-05-09 15:10 +0200
Re: [RFC] sched: low latency feedback to userspace Peter Zijlstra <peterz@infradead.org> - 2016-05-09 15:50 +0200
csiph-web