From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752570AbcEILSi (ORCPT ); Mon, 9 May 2016 07:18:38 -0400 Received: from merlin.infradead.org ([205.233.59.134]:57182 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751029AbcEILSg (ORCPT ); Mon, 9 May 2016 07:18:36 -0400 Date: Mon, 9 May 2016 13:18:31 +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: <20160509111831.GY3408@twins.programming.kicks-ass.net> References: <5730640E.9050503@fau.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5730640E.9050503@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 12:18:54PM +0200, Maximilian Krüger wrote: > I am planning to extend the CFS as part of my master thesis. I want > user-threads to allow to decide whether to enter a critical section or call > sched_yield() 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. > For tight synchronized workloads it might be useful, to only start certain > short tasks, when they still can be completed in the current time slice > without being interrupted by the scheduler. > Since low latency is key, my current plan is to use a shared-mapped page for > signaling and only use a syscall for the setup. I'd be curious, if you might > find this useful in general and if there is a chance for getting this > accepted upstream, given my benchmarks can prove gives the intended > benefits. 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. 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.