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:30:42 +0100 |
| |
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).
The whole IPI mess requires USE_GENERIC_SMP_HELPERS, which makes CONFIG_HRTICK useful (ensures we have hrtimers enabled and have generic IPI bits)
The problem is that things like hrtick_enabled() also check sched_feat(HRTICK) which is disabled by default (because programming the clock hw on each schedule was found too expensive) but that should not stop SCHED_DEADLINE from using it.
| |