Re: [PATCH] nohz1: Documentation

[Mats Liljegren <liljegren.mats2@gmail.com>]

Christoph Lameter wrote:
> On Thu, 21 Mar 2013, Paul E. McKenney wrote:
> 
> > > Yeah doing that right now but I'd like to see it handled without manual
> > > intervention.
> >
> > Given that RCU has no idea where you want them to run, some manual
> > intervention would most likely be required even if RCU spawned them
> > dynamically, right?
> 
> If rcuoXX is a SCHED_OTHER process/thread then the kernel will move it to
> another processor from the one running the SCHED_FIFO task. There would be
> no manual intervention required.
> 
> > So, again, removing scheduling-clock interrupts in more situations is
> > a good future enhancement.
> 
> The point here is that the check for a single runnable process is wrong
> because it accounts for tasks in all scheduling classes.
> 
> It would be better to check if there is only one runnable task in the
> highest scheduling class. That would work and defer the SCHED_OTHER kernel
> threads for the SCHED_FIFO thread.
> 
> I am wondering how you actually can get NOHZ to work right? There is
> always a kernel thread that is scheduled in a couple of ticks.

In my case I use 2 CPU PandaBoard where I use cpuset to create a
non-realtime domain for CPU0 and a real-time domain for CPU1. I then move
all kernel threads and IRQs to CPU0, leaving only the application specific
IRQ for CPU1. I then start a singe thread on CPU1.

I use a quite down-stripped version of Linux built using Yocto. I have run
the application for a minute and got 70-80 ticks, most (all?) occurring
during start and exit of the application. I use 100Hz ticks.

So personally I do get something by using full NOHZ in its current
incarnation. I'd like some better interrupt latency though, so disabling
 nohz-idle might be interesting for me. But that's another story...

-- Mats