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. I guess what will happens with this patchset is: 1. SCHED_FIFO thread begins to run. There is only a single runnable task so adaptive tick mode is enabled. 2. After 2 seconds or so some or other thing needs to run (keventd thread needs to run vm statistics f.e.). It becomes runnable. nr_running > 1. Adaptive tick mode is disabled? Occurs on my system. Or is there some other trick to avoid kernel threads becoming runnable? 3. Now there are 2 runnable processes. The SCHED_FIFO thread continues to run with the tick. The kernel thread is also runnable but will not be given cpu time since the SCHED_FIFO thread has priority? So the SCHED_FIFO thread enjoys 2 seconds of no tick time and then ticks occur uselessly from there on? I have not been able to consistently get the tick switched off with the nohz patchset. How do others use nohz? Is it only usable for short periods of less than 2 seconds? -- 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/
