Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755967AbcLOMQk (ORCPT ); Thu, 15 Dec 2016 07:16:40 -0500 Received: from merlin.infradead.org ([205.233.59.134]:42782 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755701AbcLOMQi (ORCPT ); Thu, 15 Dec 2016 07:16:38 -0500 Date: Thu, 15 Dec 2016 13:16:26 +0100 From: Peter Zijlstra To: Tommaso Cucinotta Cc: Ingo Molnar , Thomas Gleixner , Juri Lelli , Luca Abeni , Steven Rostedt , Claudio Scordino , Daniel Bistrot de Oliveira , Henrik Austad , linux-kernel@vger.kernel.org Subject: Re: [RFD] sched/deadline: Support single CPU affinity Message-ID: <20161215121626.GW3124@twins.programming.kicks-ass.net> References: <20161110080807.GD11311@worktop.programming.kicks-ass.net> <91d96936-7504-1578-d4e8-1f2f8d8dc113@sssup.it> <20161213102135.GJ3124@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1465 Lines: 35 On Thu, Dec 15, 2016 at 12:30:43PM +0100, Tommaso Cucinotta wrote: > Hi Peter, > > On 13/12/2016 11:21, Peter Zijlstra wrote: > >On Thu, Nov 10, 2016 at 11:01:59AM +0100, Tommaso Cucinotta wrote: > >>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 > >> > >Do I read it correct when I interpret A[t] as the number of CPUs in its > >affinity mask? > > yes, exactly, A[t] number of CPUs in the task affinity mask (sorry for my bad write-up) n/p, I got it ;-) > >Also, does recoverable mean a bound tardiness, or is that something > >weaker still? > > nope, nothing exact -- it just meant providing flexible but simple & > consistent (ie, towards recovering affinity masks) options from the > kernel/scheduler side, leaving more complex & exact tests to > user-space, or future add-ons to the kernel. So it would be good to get a more exact answer on what 'recoverable' means. It cannot mean unbounded tardiness, since that implies runaway state. It clearly doesn't mean no tardiness, as proven by the G-EDF special case. So I was hoping it would mean bounded, but possibly with a worse bound than regular G-EDF. In any case, it does provide a way to look at admission control that might be useful. I'll have to play around with it a bit.