[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F95E3F1.3030407@sssup.it>
Date: Tue, 24 Apr 2012 00:21:21 +0100
From: Tommaso Cucinotta <tommaso.cucinotta@...up.it>
To: Peter Zijlstra <peterz@...radead.org>
CC: Juri Lelli <juri.lelli@...il.com>, tglx@...utronix.de,
mingo@...hat.com, rostedt@...dmis.org, cfriesen@...tel.com,
oleg@...hat.com, fweisbec@...il.com, darren@...art.com,
johan.eker@...csson.com, p.faure@...tech.ch,
linux-kernel@...r.kernel.org, claudio@...dence.eu.com,
michael@...rulasolutions.com, fchecconi@...il.com,
nicola.manica@...i.unitn.it, luca.abeni@...tn.it,
dhaval.giani@...il.com, hgu1972@...il.com,
paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
insop.song@...csson.com, liming.wang@...driver.com
Subject: Re: [PATCH 05/16] sched: SCHED_DEADLINE policy implementation.
Il 23/04/2012 22:58, Peter Zijlstra ha scritto:
> On Mon, 2012-04-23 at 22:55 +0100, Tommaso Cucinotta wrote:
>> why not write this straight in asm, i.e., multiply 64*64 then divide by
>> 64 keeping the intermediate result on 128 bits?
> If you know of a way to do this for all 30 odd architectures supported
> by our beloved kernel, do let me know ;-)
:-)
> Yes I can do it for x86_64, but people tend to get mighty upset if you
> break the compile for all other arches...
rather than breaking compile, I was thinking more of using the
optimization for a more accurate comparison on archs that have 64-bit
mul and 128-bit cmp, and leaving the overflow on other archs. Though,
that would imply a difference in behavior on those borderline cases
(very big periods I guess).
However, I'm also puzzled from what would happen by compiling the
current code on mostly 16-bit micros which have very limited 32-bit
operations...
T.
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso
--
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/
Powered by blists - more mailing lists