From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753165AbcEINEG (ORCPT ); Mon, 9 May 2016 09:04:06 -0400 Received: from mout01.posteo.de ([185.67.36.65]:48782 "EHLO mout01.posteo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751841AbcEINEE (ORCPT ); Mon, 9 May 2016 09:04:04 -0400 Subject: Re: [RFC] sched: low latency feedback to userspace To: Peter Zijlstra References: <5730640E.9050503@fau.de> <20160509111831.GY3408@twins.programming.kicks-ass.net> Cc: Ingo Molnar , linux-kernel@vger.kernel.org From: =?UTF-8?Q?Maximilian_Kr=c3=bcger?= Message-ID: <57308ABF.8020908@fau.de> Date: Mon, 9 May 2016 15:03:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160509111831.GY3408@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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. > Schemes like this have been proposed many times (Google might find them > for you in your favourite LKML archive) and shot down the same number of > times. > > Such proposals always end up needing to define a 'limit', which is > artificial and subject to creep, also such soft preempt-disable or boost > schemes have very open ended semantics. They also become useless if > _everyone_ requests them at the same time -- something not unlikely > since every userspace program thinks it is the most important thing > under the sun. I'm totally with you in this point, which is, why I under no circumstances will prevent preemption or sacrifice the scheduler fairness, so these tasks might run longer uninterrupted, even though this still is up to discussion. Which is, why I would argue, that there would not be a benefit for tasks to use this, just because they think that they are more important than anyone else. > > > Would something like: > > http://lkml.kernel.org/r/20151027235635.16059.11630.stgit@pjt-glaptop.roam.corp.google.com > > and > > http://lkml.kernel.org/r/1459789313-4917-1-git-send-email-mathieu.desnoyers@efficios.com > > work for what you want to achieve? If not; please explain in more detail > why you want what you propose. the second patchset actually looks useful to me, but I very much agree with the comments, that this thing looks overly complicated. So yes, the interface I have in mind will be similar on an abstract level, but I don't intend any generic interface or anything close to this complexity. thanks for the the quick feedback, Max