linux-kernel - Re: [RFC][PATCH 02/11] sched: SCHED

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: <1271184954.7962.83.camel@localhost>
Date:	Tue, 13 Apr 2010 14:55:54 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Raistlin <raistlin@...ux.it>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Chris Friesen <cfriesen@...tel.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Darren Hart <darren@...art.com>,
	Henrik Austad <henrik@...tad.us>,
	Johan Eker <johan.eker@...csson.com>,
	"p.faure" <p.faure@...tech.ch>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Claudio Scordino <claudio@...dence.eu.com>,
	michael trimarchi <trimarchi@...is.sssup.it>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Tommaso Cucinotta <t.cucinotta@...up.it>,
	Juri Lelli <juri.lelli@...il.com>,
	Nicola Manica <nicola.manica@...il.com>,
	Luca Abeni <luca.abeni@...tn.it>
Subject: Re: [RFC][PATCH 02/11] sched: SCHED_DEADLINE policy implementation.

On Tue, 2010-04-13 at 20:22 +0200, Peter Zijlstra wrote:
> On Sun, 2010-02-28 at 20:17 +0100, Raistlin wrote:
> > +/*
> > + * Here we check if --at time t-- a task (which is probably being
> > + * [re]activated or, in general, enqueued) can use its remaining runtime
> > + * and its current deadline _without_ exceeding the bandwidth it is
> > + * assigned (function returns true if it can).
> > + *
> > + * For this to hold, we must check if:
> > + *   runtime / (deadline - t) < dl_runtime / dl_deadline .
> > + */
> > +static bool dl_check_bandwidth(struct sched_dl_entity *dl_se, u64 t)
> > +{
> > +       u64 left, right;
> > +
> > +       /*
> > +        * left and right are the two sides of the equation above,
> > +        * after a bit of shuffling to use multiplications instead
> > +        * of divisions.
> > +        */
> > +       left = dl_se->dl_deadline * dl_se->runtime;
> > +       right = (dl_se->deadline - t) * dl_se->dl_runtime;
> > +
> > +       return dl_time_before(left, right);
> > +} 
> 
> So what happens when we overflow u64?

Is the resolution in nanosecs starting from zero? If so, then we don't
need to worry about overflow for 583 years? And that is only if the
difference in time is greater than 292 years since dl_time_before() does
a:

  (s64)(a - b) < 0

The (s64)(a - b) returns the difference even on overflow as long as the
difference is not greater than 2^63


-- Steve


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