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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1263401221.4244.250.camel@laptop>
Date:	Wed, 13 Jan 2010 17:47:01 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Dario Faggioli <faggioli@...dalf.sssup.it>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	michael trimarchi <michael@...dence.eu.com>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Johan Eker <johan.eker@...csson.com>,
	"p.faure" <p.faure@...tech.ch>,
	Chris Friesen <cfriesen@...tel.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Henrik Austad <henrik@...tad.us>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Darren Hart <darren@...art.com>,
	Sven-Thorsten Dietrich <sven@...bigcorporation.com>,
	Claudio Scordino <claudio@...dence.eu.com>,
	Tommaso Cucinotta <tommaso.cucinotta@...up.it>,
	"giuseppe.lipari" <giuseppe.lipari@...up.it>,
	Juri Lelli <juri.lelli@...il.com>
Subject: Re: [RFC 0/12][PATCH] SCHED_DEADLINE: core of the scheduling class

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..

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/