Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756849Ab0KKObT (ORCPT ); Thu, 11 Nov 2010 09:31:19 -0500 Received: from canuck.infradead.org ([134.117.69.58]:59710 "EHLO canuck.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755190Ab0KKObS convert rfc822-to-8bit (ORCPT ); Thu, 11 Nov 2010 09:31:18 -0500 Subject: Re: [RFC][PATCH 06/22] sched: SCHED_DEADLINE handles spacial kthreads From: Peter Zijlstra To: Raistlin Cc: Ingo Molnar , Thomas Gleixner , Steven Rostedt , Chris Friesen , oleg@redhat.com, Frederic Weisbecker , Darren Hart , Johan Eker , "p.faure" , linux-kernel , Claudio Scordino , michael trimarchi , Fabio Checconi , Tommaso Cucinotta , Juri Lelli , Nicola Manica , Luca Abeni , Dhaval Giani , Harald Gustafsson , paulmck In-Reply-To: <1288333876.8661.147.camel@Palantir> References: <1288333128.8661.137.camel@Palantir> <1288333876.8661.147.camel@Palantir> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Thu, 11 Nov 2010 15:31:01 +0100 Message-ID: <1289485861.2084.122.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1884 Lines: 43 On Fri, 2010-10-29 at 08:31 +0200, Raistlin wrote: > > There sometimes is the need of executing a task as if it would > have the maximum possible priority in the entire system, i.e., > whenever it gets ready it must run! This is for example the case > for some maintainance kernel thread like migration and (sometimes) > watchdog or ksoftirq. > > Since SCHED_DEADLINE is now the highest priority scheduling class > these tasks have to be handled therein, but it is not obvious how > to choose a runtime and a deadline that guarantee what explained > above. Therefore, we need a mean of recognizing system tasks inside > the -deadline class and always run them as soon as possible, without > any kind of runtime and bandwidth limitation. > > This patch: > - adds the SF_HEAD flag, which identify a special task that need > absolute prioritization among any other task; > - ensures that special tasks always preempt everyone else (and, > obviously, are not preempted by non special tasks); > - disables runtime and bandwidth checking for such tasks, hoping > that the interference they cause is small enough. > Yet in the previous patch you had this hunk: > +++ b/kernel/sched_stoptask.c > @@ -81,7 +81,7 @@ get_rr_interval_stop(struct rq *rq, struct > task_struct *task) > * Simple, special scheduling class for the per-CPU stop tasks: > */ > static const struct sched_class stop_sched_class = { > - .next = &rt_sched_class, > + .next = &dl_sched_class, > > .enqueue_task = enqueue_task_stop, > .dequeue_task = dequeue_task_stop, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/