From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751908AbcEIKTC (ORCPT ); Mon, 9 May 2016 06:19:02 -0400 Received: from mout01.posteo.de ([185.67.36.65]:45463 "EHLO mout01.posteo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751188AbcEIKTA (ORCPT ); Mon, 9 May 2016 06:19:00 -0400 From: =?UTF-8?Q?Maximilian_Kr=c3=bcger?= To: Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org Subject: [RFC] sched: low latency feedback to userspace Message-ID: <5730640E.9050503@fau.de> Date: Mon, 9 May 2016 12:18:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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() 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. While these are very general questions, I have one detail question concerning how good the chances for getting this upstream are. Would you prefer, if I implemented the setup with an additional syscall, or as an extensions of existing syscalls (probably sched_setattr, sched_getattr). greetings, Maximilian Krüger