From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755981AbcAOIPn (ORCPT ); Fri, 15 Jan 2016 03:15:43 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:35632 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755930AbcAOIPl (ORCPT ); Fri, 15 Jan 2016 03:15:41 -0500 Subject: Re: [RFC 7/8] Make GRUB a task's flag To: Peter Zijlstra References: <1452785094-3086-1-git-send-email-luca.abeni@unitn.it> <1452785094-3086-8-git-send-email-luca.abeni@unitn.it> <20160114195651.GG6357@twins.programming.kicks-ass.net> Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Juri Lelli From: Luca Abeni Message-ID: <5698AAAB.9040606@unitn.it> Date: Fri, 15 Jan 2016 09:15:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160114195651.GG6357@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 On 01/14/2016 08:56 PM, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 04:24:52PM +0100, Luca Abeni wrote: >> +++ b/include/uapi/linux/sched.h >> @@ -48,5 +48,6 @@ >> * For the sched_{set,get}attr() calls >> */ >> #define SCHED_FLAG_RESET_ON_FORK 0x01 >> +#define SCHED_FLAG_RECLAIM 0x02 > > With an eye towards unpriv usage of SCHED_DEADLINE, this isn't something > we could allow unpriv tasks, right? Since (IIRC) GRUB will allow eating > all !deadline time. The original algorithm, yes, it allowed to use 100% of the CPU time, starving all !deadline tasks. But in this patchset I modified the algorithm to allow reclaiming only a fraction U_max of the CPU time... So, 1-U_max can be left free for !deadline. > Something with an average runtime/budget that also puts limits on the > max (say 2*avg) would be far more amenable to be exposed to unpriv > tasks, except since that would directly result in an average tardiness > bound this might be non-trivial to combine with tasks not opting for > this. I'll try to think about this... The advantage of GRUB is that a theoretically sound algorithm already existed; here, we would need to design the algorithm so that it does not break the SCHED_DEADLINE guarantees. Anyway, this is an interesting challenge, I'll work on it :) Thanks, Luca