Date:	Thu, 25 Oct 2012 15:26:03 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Juri Lelli <juri.lelli@...il.com>, tglx@...utronix.de,
	mingo@...hat.com, rostedt@...dmis.org, 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, tommaso.cucinotta@...up.it,
	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,
	jkacur@...hat.com, harald.gustafsson@...csson.com,
	vincent.guittot@...aro.org, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 01/16] math128: Introduce various 128bit primitives

On Thu, Oct 25, 2012 at 6:47 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, 2012-10-24 at 16:18 -0700, Linus Torvalds wrote:
>>
>> So please, explain what the pressing need is that is so worthwhile
>> that this is worth it. Maybe it was in a 00/16 cover letter, but not
>> only was that not sent out to the people who got 01, you'd still want
>> it in the commit message.
>
> There's two use cases:
>
>  1) the proposed SCHED_DEADLINE needs to do some u64xu64 math, it
>     ends up having to multiply a deadline (in usec) with runtime (also
>     in usec).
>
>  2) the infrastructure adds mul_u64_u32_shr(), which is something we
>     do a lot of with all the time manipulation, apply a multiplier to
>     some u64 clock value.
>
>     We can do better on some archs than we can in generic, so this
>     interface could give a win there.

So I have no objection to the mul_u64_u32_shr() model, exactly because

 - it doesn't actually use u128 anywhere (except perhaps internally,
but that is totally about the implementation, not visible anywhere
else).

 - it is fundamentally optimizable especially on 32-bit architectures
where it doesn't need to do a full 64x64 multiply.

it's the *rest* of the "u128" math I really object to. I also wonder
about the u64xu64 math case for SCHED_DEADLINE, because I assume that
it doesn't actually end up using the 128-bit result in that form, but
scales it down again some way?

In other words, the thing I really object to is exactly the whole
"generic 128-bit math". That's the part that can easily get very
expensive in 32-bit environments. Even for the "u64xu64" multiply for
SCHED_DEADLINE, how could it possibly be true 64-bit values (even if
your "usec" was wrong, and it's "nsec").

At what point does the scheduler talk/think about billions of seconds
in nanoseconds? Seriously?

That's a perfect example of where "true 128-bit math" is potentially
stupidly expensive on 32-bit platforms, when a 48x48->96 bit multiply
might be cheaper. And if we're talking about some fixed-point
arithmetic, and the thing actually gets shifted down again (like the
mul_u64_u32_shr) so that the final result is actually guaranteed to
fit in (say) 64 bits, then that would be cheaper yet.

I realize that some people seem to think that being "generic" is
superior, and think that maybe somebody wants to do 128-bit arithmetic
for other things. And I think that is exactly the wrong way to think,
because it just encourages people to do exactly the wrong thing,
because "look, 128-bit arithmetic is easily available so I can do
fancy things", and then it just happens to go really fast on x86-64,
and then sucks everywhere else.

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