[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1363891462.6345.52.camel@gandalf.local.home>
Date: Thu, 21 Mar 2013 14:44:22 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: paulmck@...ux.vnet.ibm.com
Cc: Christoph Lameter <cl@...ux.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Rob Landley <rob@...dley.net>, linux-kernel@...r.kernel.org,
josh@...htriplett.org, zhong@...ux.vnet.ibm.com,
khilman@...aro.org, geoff@...radead.org, tglx@...utronix.de
Subject: Re: [PATCH] nohz1: Documentation
On Thu, 2013-03-21 at 10:15 -0700, Paul E. McKenney wrote:
> > The OS always has some sched other tasks around that become runnable after
> > a while (like for example the vm statistics update, or the notorious slab
> > scanning). As long as SCHED_FIFO is active and there is no process in the
> > same scheduling class then tick needs to be off. Also wish that this would
> > work with SCHED_OTHER if there is only a single task with a certain renice
> > value (-10?) and the rest is runnable at lower priorities. Maybe in that
> > case stop the tick for a longer period and then give the lower priority
> > tasks a chance to run but then switch off the tick again.
>
> These sound to me like good future enhancements.
Exactly. Please, this is a complex enough change to something that is
critical to the entire system (similar to RCU itself). Lets take baby
steps here and get it right each step of the way.
For now, no, if more than one process is scheduled on the CPU, we fall
out of dynamic tick mode. In the future, we can add SCHED_FIFO task
scheduled in to trigger it. But lets conquer that after we successfully
conquer the current changes.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists