Messages in this thread | | | Subject | Re: [PATCH 04/32] x86: New cpuset nohz irq vector | From | Steven Rostedt <> | Date | Tue, 30 Oct 2012 20:07:53 -0400 |
| |
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
| |