Messages in this thread | | | Date | Fri, 22 Mar 2013 10:52:47 +0100 | From | Mats Liljegren <> | Subject | Re: [PATCH] nohz1: Documentation |
| |
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
| |