Messages in this thread | | | Subject | Re: [RFC 0/12][PATCH] SCHED_DEADLINE: core of the scheduling class | From | Peter Zijlstra <> | Date | Tue, 29 Dec 2009 15:37:02 +0100 |
| |
On Tue, 2009-12-29 at 15:30 +0100, Peter Zijlstra wrote: > On Fri, 2009-10-16 at 17:40 +0200, Raistlin wrote: > > +struct task_struct *pick_next_task_deadline(struct rq *rq) > > +{ > > + struct sched_dl_entity *dl_se; > > + struct task_struct *p; > > + struct dl_rq *dl_rq; > > + > > + dl_rq = &rq->dl; > > + > > + if (likely(!dl_rq->dl_nr_running)) > > + return NULL; > > + > > + dl_se = pick_next_deadline_entity(rq, dl_rq); > > + BUG_ON(!dl_se); > > + > > + p = deadline_task_of(dl_se); > > + p->se.exec_start = rq->clock; > > +#ifdef CONFIG_SCHED_HRTICK > > + if (hrtick_enabled(rq)) > > + start_hrtick_deadline(rq, p); > > +#endif > > + return p; > > +} > > I'm not sure about actually using hrtick like this, I'd expect > SCHED_DEADLINE to always use hrtimers when available. The only reason > to use some of the hrtick infrastructure is to re-use the hrtick_start() > logic which uses IPIs to ensure we program the timer on the right cpu > (so we can schedule from it).
Hmm I suppose we could ignore all that CONFIG_SCHED_HRTICK stuff and simply bounce the schedule event using the resched ipi when we find we're on the wrong cpu. Not ideal though.. frigging mess all this :-)
| |