On Wed, 2012-10-31 at 00:51 +0100, Frederic Weisbecker wrote: > > Probably just use irq_work for self ipis, and normal ipis for other > > CPUs. > > Right. And that's one more reason why we want to know if the arch > implements irq work with self ipis or not. If the arch can't, then we > just don't stop the tick.
We can just allow certain archs to have cpuset/nohz. Make it depend on features that you want (or makes nohz easier to implement). > > > Also, what reason do we have to force a task out of nohz? IOW, do we > > really need this? > > When a posix CPU timer is enqueued, when a new task is enqueued, etc... I was thinking about something other than itself. That is, who would enqueue a posix cpu timer on the cpu other than the task running with nohz on that cpu? A new task would send the schedule ipi too. Which would enqueue the task and take the cpu out of nohz, no? > > > > > Also, perhaps we could just tag onto the schedule_ipi() function instead > > of having to create a new IPI for all archs? > > irq work should be just fine. No need to add more overhead on the > schedule ipi I think. irq_work can send the work to another CPU right? This part I wasn't sure about. -- Steve -- 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/
