On 12/9/2016 5:18 AM, Peter Zijlstra wrote:
On Fri, Dec 09, 2016 at 07:38:47AM +0100, Peter Zijlstra wrote:
Turns out using GCC-6.2.1 we have the same problem on i386, GCC doesn't
recognise the 32x32 mults and generates crap.
This used to work :/
I tried:
gcc-4.4: good
gcc-4.6, gcc-4.8, gcc-
On 12/9/2016 3:30 AM, Peter Zijlstra wrote:
On Fri, Dec 09, 2016 at 07:38:47AM +0100, Peter Zijlstra wrote:
On Fri, Dec 09, 2016 at 06:26:38AM +0100, Peter Zijlstra wrote:
Just for giggles, on tilegx the branch is actually slower than doing the
mult unconditionally.
The problem is that the two
On Fri, Dec 09, 2016 at 07:38:47AM +0100, Peter Zijlstra wrote:
> Turns out using GCC-6.2.1 we have the same problem on i386, GCC doesn't
> recognise the 32x32 mults and generates crap.
>
> This used to work :/
I tried:
gcc-4.4: good
gcc-4.6, gcc-4.8, gcc-5.4, gcc-6.2: bad
On Fri, Dec 09, 2016 at 09:30:11AM +0100, Peter Zijlstra wrote:
> +static inline u64 mul_u32_u32(u32 a, u32 b)
> +{
> + u64 ret;
> +
> + asm ("mull %[b]" : "=A" (ret) : [a] "a" (a), [b] "g" (b) );
> +
> + return ret;
> +}
ARGH, that's broken on x86_64, it needs to be:
u32 high
On Fri, Dec 09, 2016 at 09:30:11AM +0100, Peter Zijlstra wrote:
> > > Just for giggles, on tilegx the branch is actually slower than doing the
> > > mult unconditionally.
> > >
> > > The problem is that the two multiplies would otherwise completely
> > > pipeline, whereas with the conditional you
On Fri, Dec 09, 2016 at 07:38:47AM +0100, Peter Zijlstra wrote:
> On Fri, Dec 09, 2016 at 06:26:38AM +0100, Peter Zijlstra wrote:
> > Just for giggles, on tilegx the branch is actually slower than doing the
> > mult unconditionally.
> >
> > The problem is that the two multiplies would otherwise c
On Fri, Dec 09, 2016 at 06:26:38AM +0100, Peter Zijlstra wrote:
> On Thu, Dec 08, 2016 at 08:49:39PM -, Thomas Gleixner wrote:
>
> > +static inline u64 timekeeping_delta_to_ns(struct tk_read_base *tkr, u64
> > delta)
> > +{
> > + u32 dh, dl;
> > + u64 nsec;
> > +
> > + dl = delta;
> > +
On Fri, Dec 09, 2016 at 06:11:17AM +0100, Peter Zijlstra wrote:
> On Thu, Dec 08, 2016 at 08:49:39PM -, Thomas Gleixner wrote:
>
> > +/*
> > + * Enabled when timekeeping is supposed to deal with virtualization keeping
> > + * VMs long enough scheduled out that the 64 * 32 bit multiplication in
On Fri, Dec 09, 2016 at 06:22:03AM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Fri, Dec 09, 2016 at 05:08:26AM +0100, Ingo Molnar wrote:
> > > > +#if defined(CONFIG_ARCH_SUPPORTS_INT128) && defined(__SIZEOF_INT128__)
> > > > +static inline u64 timekeeping_delta_to_ns(struct tk
On Thu, Dec 08, 2016 at 08:49:39PM -, Thomas Gleixner wrote:
> +static inline u64 timekeeping_delta_to_ns(struct tk_read_base *tkr, u64
> delta)
> +{
> + u32 dh, dl;
> + u64 nsec;
> +
> + dl = delta;
> + dh = delta >> 32;
> +
> + nsec = ((u64)dl * tkr->mult) + tkr->xtime_n
* Peter Zijlstra wrote:
> On Fri, Dec 09, 2016 at 05:08:26AM +0100, Ingo Molnar wrote:
> > > +#if defined(CONFIG_ARCH_SUPPORTS_INT128) && defined(__SIZEOF_INT128__)
> > > +static inline u64 timekeeping_delta_to_ns(struct tk_read_base *tkr, u64
> > > delta)
> > > +{
> > > + unsigned __int128 nse
On Thu, Dec 08, 2016 at 08:49:39PM -, Thomas Gleixner wrote:
> +/*
> + * Enabled when timekeeping is supposed to deal with virtualization keeping
> + * VMs long enough scheduled out that the 64 * 32 bit multiplication in
> + * timekeeping_delta_to_ns() overflows 64bit.
> + */
> +#ifdef CONFIG_
On Fri, Dec 09, 2016 at 05:08:26AM +0100, Ingo Molnar wrote:
> > +#if defined(CONFIG_ARCH_SUPPORTS_INT128) && defined(__SIZEOF_INT128__)
> > +static inline u64 timekeeping_delta_to_ns(struct tk_read_base *tkr, u64
> > delta)
> > +{
> > + unsigned __int128 nsec;
> > +
> > + nsec = ((unsigned __
On Thu, Dec 8, 2016 at 8:29 PM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>>
>> * Thomas Gleixner wrote:
>>
>> > If the timekeeping CPU is scheduled out long enough by a hypervisor the
>> > clocksource delta multiplication can overflow and as a result time can go
>> > backwards. That's insan
* Ingo Molnar wrote:
>
> * Thomas Gleixner wrote:
>
> > If the timekeeping CPU is scheduled out long enough by a hypervisor the
> > clocksource delta multiplication can overflow and as a result time can go
> > backwards. That's insane to begin with, but people already triggered a
> > signed m
* Thomas Gleixner wrote:
> If the timekeeping CPU is scheduled out long enough by a hypervisor the
> clocksource delta multiplication can overflow and as a result time can go
> backwards. That's insane to begin with, but people already triggered a
> signed multiplication overflow, so a unsigned
If the timekeeping CPU is scheduled out long enough by a hypervisor the
clocksource delta multiplication can overflow and as a result time can go
backwards. That's insane to begin with, but people already triggered a
signed multiplication overflow, so a unsigned overflow is not necessarily
impossib
17 matches
Mail list logo
