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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
