Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754878AbcKJKB4 (ORCPT ); Thu, 10 Nov 2016 05:01:56 -0500 Received: from ms01.sssup.it ([193.205.80.99]:64661 "EHLO sssup.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753466AbcKJKBy (ORCPT ); Thu, 10 Nov 2016 05:01:54 -0500 Subject: Re: [RFD] sched/deadline: Support single CPU affinity To: Peter Zijlstra , Ingo Molnar , Thomas Gleixner References: <20161110080807.GD11311@worktop.programming.kicks-ass.net> Cc: Juri Lelli , Luca Abeni , Steven Rostedt , Claudio Scordino , Daniel Bistrot de Oliveira , Henrik Austad , linux-kernel@vger.kernel.org From: Tommaso Cucinotta Message-ID: <91d96936-7504-1578-d4e8-1f2f8d8dc113@sssup.it> Date: Thu, 10 Nov 2016 11:01:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161110080807.GD11311@worktop.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 Content-Length: 2239 Lines: 38 Hi, On 10/11/2016 09:08, Peter Zijlstra wrote: > Add support for single CPU affinity to SCHED_DEADLINE; the supposed reason for > wanting single CPU affinity is better QoS than provided by G-EDF. > > Therefore the aim is to provide harder guarantees, similar to UP, for single > CPU affine tasks. This then leads to a mixed criticality scheduling > requirement for the CPU scheduler. G-EDF like for the non-affine (global) > tasks and UP like for the single CPU tasks. > > > > ADMISSION CONTROL > > Do simple UP admission control on the CPU local tasks, and subtract the > admitted bandwidth from the global total when doing global admission control. > > single cpu: U[n] := \Sum tl_u,n <= 1 > global: \Sum tg_u <= N - \Sum U[n] +1, even with the current G-EDF: we need in the kernel a minimum permissive admission control simple enough to just avoid ill-formed workloads that pile-up forever without hope of recovering (as opposed to an AC that runs a complex test and doesn't allow you to deploy a task unless it's absolutely guaranteed to schedule its runtime by its deadline), even though it won't be perfect in terms of hard RT guarantees; the latter would require anyway more complex analysis techniques, considering also frequency of interrupts & the likes, and can be done in user-space by proper middleware, libraries, or even at design-time for static embedded systems where everything is known upfront and doesn't change often. That said, it's good if in addition the mechanism behaves well from an analysis viewpoint (and we have a tardiness bound), the only problem being that there's a zillion proposals in research (see upcoming reply to Luca's). Just a note: if you want to recover arbitrary task affinities, you can re-cast your above test like this: for_each_processor(cpu) \sum U[t]/A[t] \leq 1 (or U_max), for each task t on cpu, with utilization U[t] and A[t] tasks overall in its affinity mask (I'm not claiming we need scenarios with overlapping cpusets and G-EDF tasks, it's just in case it simplifies code) T. -- Tommaso Cucinotta, Computer Engineering PhD Associate Professor at the Real-Time Systems Laboratory (ReTiS) Scuola Superiore Sant'Anna, Pisa, Italy http://retis.sssup.it/people/tommaso