Re: [RFC 0/12][PATCH] SCHED_DEADLINE: core of the scheduling class

[Peter Zijlstra <peterz@infradead.org>]

On Wed, 2010-01-13 at 17:32 +0100, Dario Faggioli wrote:
> 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).
> > 
> Yeah, that and the fact that it seemed to me very easy and clean to:
> - check for runtime enforcement inside the task_tick_deadline function,
>   as other scheduling classes do, and then
> - if possible, ask that task_tick_deadline function to be called right 
>   at the time instant I expect my runtime to be depleted. If that won't 
>   happen --because of no-hrtick or no-hires-hrtimers-- the check will
>   still be performed during the next tick.
> 
> > 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.
> > 
> Mmm... I might have lost you here... :-(

I had a little chat with fabio around new-years and I think we ended up
agreeing that your current usage is ok, we can always fix it up later.

Its an unfortunate complicated dance of hrtimer being configured in,
having capable hardware and dealing with all the fallout cases.

The only thing which is unfortunate for your current usage is the
sched_feat(HRTICK) thing, we generally do not want HRTICK for
SCHED_OTHER, whereas we'd always (when configured and having capable
hardware) want if for SCHED_DEADLINE..