From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751832AbcEINmi (ORCPT ); Mon, 9 May 2016 09:42:38 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:56903 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750879AbcEINmh (ORCPT ); Mon, 9 May 2016 09:42:37 -0400 Date: Mon, 9 May 2016 15:42:34 +0200 From: Peter Zijlstra To: Maximilian =?iso-8859-1?Q?Kr=FCger?= Cc: Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [RFC] sched: low latency feedback to userspace Message-ID: <20160509134234.GZ3408@twins.programming.kicks-ass.net> References: <5730640E.9050503@fau.de> <20160509111831.GY3408@twins.programming.kicks-ass.net> <57308ABF.8020908@fau.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <57308ABF.8020908@fau.de> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 :/