On Thu, Dec 12, 2013 at 07:06:57AM -0800, H. Peter Anvin wrote:
> On 12/12/2013 05:28 AM, Ingo Molnar wrote:
> >>
> >> The reason we use thread_info::flags is because we need to write
> >> TIF_NEED_RESCHED into it to wake up anyhow.
> >>
> >> Using another cacheline would mean the wakeup path would
On 12/12/2013 05:28 AM, Ingo Molnar wrote:
>>
>> The reason we use thread_info::flags is because we need to write
>> TIF_NEED_RESCHED into it to wake up anyhow.
>>
>> Using another cacheline would mean the wakeup path would need to write a
>> second cross cpu cacheline -- that is badness too.
>>
>>
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
> > On 12/11/2013 09:50 AM, Ingo Molnar wrote:
> > >
> > > Well, availability could be a problem too, if some CPU (real or
> > > virtual) implements MWAIT but not CLFLUSH.
> > >
> > > In theory we could
On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
> On 12/11/2013 09:50 AM, Ingo Molnar wrote:
> >
> > Well, availability could be a problem too, if some CPU (real or
> > virtual) implements MWAIT but not CLFLUSH.
> >
> > In theory we could make mwait an alternatives variant and pa
I'm guessing there is an implicit or explicit wake-up somewhere that I managed
to miss. If it is implicit it could be hard to catch.
Mike Galbraith wrote:
>On Thu, 2013-12-12 at 06:57 +0100, Mike Galbraith wrote:
>> On Wed, 2013-12-11 at 21:45 -0800, H. Peter Anvin wrote:
>> > As in it hangs
On Thu, 2013-12-12 at 06:57 +0100, Mike Galbraith wrote:
> On Wed, 2013-12-11 at 21:45 -0800, H. Peter Anvin wrote:
> > As in it hangs at that point?
>
> Nope, it's still going.
>
> [1567.578340] pcc-cpufreq: (v1.10.00) driver loaded with frequency limits:
> 1064 MHz, 2266 MHz
>
> Funny, cont
On Wed, 2013-12-11 at 21:45 -0800, H. Peter Anvin wrote:
> As in it hangs at that point?
Nope, it's still going.
[1567.578340] pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1064
MHz, 2266 MHz
Funny, continents move faster :) Maybe missing a write or two.
-Mike
--
To unsubscri
As in it hangs at that point?
Mike Galbraith wrote:
>On Wed, 2013-12-11 at 20:49 -0800, H. Peter Anvin wrote:
>> On 12/11/2013 08:25 PM, Mike Galbraith wrote:
>> > arch/x86/include/asm/mwait.h |4 ++--
>> > arch/x86/kernel/cpu/common.c |7 ---
>> > arch/x86/kernel/setup_percpu.c
On Wed, 2013-12-11 at 20:49 -0800, H. Peter Anvin wrote:
> On 12/11/2013 08:25 PM, Mike Galbraith wrote:
> > arch/x86/include/asm/mwait.h |4 ++--
> > arch/x86/kernel/cpu/common.c |7 ---
> > arch/x86/kernel/setup_percpu.c |1 +
> > 3 files changed, 7 insertions(+), 5 deletion
On Wed, 2013-12-11 at 20:49 -0800, H. Peter Anvin wrote:
> On 12/11/2013 08:25 PM, Mike Galbraith wrote:
> > arch/x86/include/asm/mwait.h |4 ++--
> > arch/x86/kernel/cpu/common.c |7 ---
> > arch/x86/kernel/setup_percpu.c |1 +
> > 3 files changed, 7 insertions(+), 5 deletion
On 12/11/2013 08:25 PM, Mike Galbraith wrote:
> arch/x86/include/asm/mwait.h |4 ++--
> arch/x86/kernel/cpu/common.c |7 ---
> arch/x86/kernel/setup_percpu.c |1 +
> 3 files changed, 7 insertions(+), 5 deletions(-)
>
> Index: linux-2.6/arch/x86/kernel/cpu/common.c
> ==
On Wed, 2013-12-11 at 16:52 -0800, H. Peter Anvin wrote:
> On 12/11/2013 03:14 PM, Borislav Petkov wrote:
> > On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
> >> So I would like to propose that we switch to using a percpu variable
> >> which is a single cache line of nothing at al
On 12/11/2013 03:14 PM, Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
>> So I would like to propose that we switch to using a percpu variable
>> which is a single cache line of nothing at all. It would only ever
>> be touched by MONITOR and for explicit wa
On Wed, Dec 11, 2013 at 03:08:35PM -0800, H. Peter Anvin wrote:
> So I would like to propose that we switch to using a percpu variable
> which is a single cache line of nothing at all. It would only ever
> be touched by MONITOR and for explicit wakeup. Hopefully that will
> resolve this problem wit
On 12/11/2013 09:50 AM, Ingo Molnar wrote:
>
> Well, availability could be a problem too, if some CPU (real or
> virtual) implements MWAIT but not CLFLUSH.
>
> In theory we could make mwait an alternatives variant and patch in the
> right combination of instructions? The CLFLUSH goes to the sam
On Wed, 11 Dec 2013, Len Brown wrote:
> For the record...
>
> intel_idle doesn't check that bit because it doesn't run on model 29 --
> the Xeon 7400 was the "Dunnington" 4-socket generation based on Core2.
Right, we wondered about the restricted model check
already. Interesting that this is a 4
For the record...
intel_idle doesn't check that bit because it doesn't run on model 29 --
the Xeon 7400 was the "Dunnington" 4-socket generation based on Core2.
Until now, i was not aware that this issue might apply to models other
than that one.
Checking w/ the HW guys...
thanks,
Len Brown, Int
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 03:56:55PM +0100, Ingo Molnar wrote:
> >
> > * Borislav Petkov wrote:
> >
> > > On Wed, Dec 11, 2013 at 01:43:52PM +0100, Peter Zijlstra wrote:
> > > > Something like the below.. someone needs to double check and possibly
> > > > add SNB/IVB E
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 04:09:11PM +0100, Ingo Molnar wrote:
> >
> > * Thomas Gleixner wrote:
> >
> > > On Wed, 11 Dec 2013, Ingo Molnar wrote:
> > > >
> > > > Another thing that is required I think is to issue a write barrier
> > > > before CLFLUSH instruction. By
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 03:42:38PM +0100, Ingo Molnar wrote:
> > Another thing that is required I think is to issue a write barrier
> > before CLFLUSH instruction. By my (possibly incorrect ...) reading of
> > the documentation CLFLUSH does not appear to be ordered (a
On Wed, Dec 11, 2013 at 04:09:11PM +0100, Ingo Molnar wrote:
>
> * Thomas Gleixner wrote:
>
> > On Wed, 11 Dec 2013, Ingo Molnar wrote:
> > >
> > > Another thing that is required I think is to issue a write barrier
> > > before CLFLUSH instruction. By my (possibly incorrect ...) reading of
>
On Wed, Dec 11, 2013 at 03:42:38PM +0100, Ingo Molnar wrote:
> Another thing that is required I think is to issue a write barrier
> before CLFLUSH instruction. By my (possibly incorrect ...) reading of
> the documentation CLFLUSH does not appear to be ordered (at all), so
> it might execute befo
On Wed, Dec 11, 2013 at 03:56:55PM +0100, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > On Wed, Dec 11, 2013 at 01:43:52PM +0100, Peter Zijlstra wrote:
> > > Something like the below.. someone needs to double check and possibly
> > > add SNB/IVB EX parts if they're already available.
> >
On Wed, Dec 11, 2013 at 03:56:55PM +0100, Ingo Molnar wrote:
> I think CLFLUSH should be pretty universally available, IIRC
> graphics drivers were using it rather heavily in combination with
> write-combining MTRRs, both on Linux and on Windows.
... and it is also very expensive. So I don't think
* Thomas Gleixner wrote:
> On Wed, 11 Dec 2013, Ingo Molnar wrote:
> >
> > Another thing that is required I think is to issue a write barrier
> > before CLFLUSH instruction. By my (possibly incorrect ...) reading of
> > the documentation CLFLUSH does not appear to be ordered (at all), so
> >
On Wed, 11 Dec 2013, Ingo Molnar wrote:
>
> Another thing that is required I think is to issue a write barrier
> before CLFLUSH instruction. By my (possibly incorrect ...) reading of
> the documentation CLFLUSH does not appear to be ordered (at all), so
> it might execute before the modificatio
* Borislav Petkov wrote:
> On Wed, Dec 11, 2013 at 01:43:52PM +0100, Peter Zijlstra wrote:
> > Something like the below.. someone needs to double check and possibly
> > add SNB/IVB EX parts if they're already available.
>
> Right, our friends at Intel would need to tell us which families/models
* Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 01:29:15PM +0100, Mike Galbraith wrote:
> > On Wed, 2013-12-11 at 12:52 +0100, Peter Zijlstra wrote:
> > > On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> > > > Right, if it turns out that this is really the case and that this
On Wed, Dec 11, 2013 at 01:43:52PM +0100, Peter Zijlstra wrote:
> Something like the below.. someone needs to double check and possibly
> add SNB/IVB EX parts if they're already available.
Right, our friends at Intel would need to tell us which families/models
does AAI65 span... if, this is actual
On Wed, 2013-12-11 at 13:43 +0100, Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 01:29:15PM +0100, Mike Galbraith wrote:
> > On Wed, 2013-12-11 at 12:52 +0100, Peter Zijlstra wrote:
> > > On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> > > > Right, if it turns out that this i
On Wed, Dec 11, 2013 at 01:29:15PM +0100, Mike Galbraith wrote:
> On Wed, 2013-12-11 at 12:52 +0100, Peter Zijlstra wrote:
> > On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> > > Right, if it turns out that this is really the case and that this
> > > erratum hasn't been fixed fo
On Wed, 2013-12-11 at 12:52 +0100, Peter Zijlstra wrote:
> On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> > Right, if it turns out that this is really the case and that this
> > erratum hasn't been fixed for models later than 29 - we'd need the
> > additional model numbers to s
On Wed, Dec 11, 2013 at 12:38:39PM +0100, Borislav Petkov wrote:
> Right, if it turns out that this is really the case and that this
> erratum hasn't been fixed for models later than 29 - we'd need the
> additional model numbers to set X86_FEATURE_CLFLUSH_MONITOR correctly.
You also need: https://
On Wed, Dec 11, 2013 at 12:28:36PM +0100, Thomas Gleixner wrote:
> On Wed, 11 Dec 2013, Mike Galbraith wrote:
> > Alakazam..
> > Yup, magical gremlin repellent works on 8 socket DL980 too.
>
> Now here is a less magical version of the gremlin repellent.
>
> And just for the amusement value: The e
On Wed, 11 Dec 2013, Mike Galbraith wrote:
> Alakazam..
> Yup, magical gremlin repellent works on 8 socket DL980 too.
Now here is a less magical version of the gremlin repellent.
And just for the amusement value: The erratum for the series 7400
says:
AAI65. MONITOR/MWAIT May Have Excessive False
Alakazam..
pk cor CPU%c0 GHz TSC SMI%c1%c3%c6 CTMP %pc3 %pc6
0.17 2.01 2.26 0 0.02 99.82 0.00 49 99.55 0.00
0 0 0 0.95 1.45 2.26 2 0.43 98.62 0.00 48 98.48 0.00
1 0 8 0.24 1.99 2.26 2 0.02 99.75 0.00 38 99.68 0.00
On Tue, 10 Dec 2013, Thomas Gleixner wrote:
> On Tue, 10 Dec 2013, Mike Galbraith wrote:
> > vogelweide:~/:[130]# turbostat -P -i 60
> > pk cor CPU%c0 GHz TSC SMI%c1%c3%c6 CTMP %pc3 %pc6
> > 0.02 2.12 2.26 0 43.40 56.57 0.00 53 33.81 0.00
> > 0 0 0
* Thomas Gleixner wrote:
> On Tue, 10 Dec 2013, Mike Galbraith wrote:
> > vogelweide:~/:[130]# turbostat -P -i 60
> > pk cor CPU%c0 GHz TSC SMI%c1%c3%c6 CTMP %pc3 %pc6
> > 0.02 2.12 2.26 0 43.40 56.57 0.00 53 33.81 0.00
> > 0 0 0 0.23 2.10 2.2
On Tue, 10 Dec 2013, Mike Galbraith wrote:
> vogelweide:~/:[130]# turbostat -P -i 60
> pk cor CPU%c0 GHz TSC SMI%c1%c3%c6 CTMP %pc3 %pc6
> 0.02 2.12 2.26 0 43.40 56.57 0.00 53 33.81 0.00
> 0 0 0 0.23 2.10 2.26 5 65.47 34.30 0.00 52 10.69
* Mike Galbraith wrote:
> Hi Len,
>
> I'm unable to reproduce those DL980 results. I updated the kernel and
> config yesterday, and happened to run turbostat again.. and the box was
> nowhere near as quiet. I ended up spending all day futzing with the
> darn thing, checking various config/ker
* Mike Galbraith wrote:
> On Sat, 2013-12-07 at 11:45 -0500, Len Brown wrote:
> > >> It fixes that, except for my Q6600 box. Too bad mwait_idle() went away,
> > >> beloved old box doesn't play hints game, so it continues to flog itself.
> >
> >
> > Thanks for pointing this out, Mike!
> >
>
Hi Len,
I'm unable to reproduce those DL980 results. I updated the kernel and
config yesterday, and happened to run turbostat again.. and the box was
nowhere near as quiet. I ended up spending all day futzing with the
darn thing, checking various config/kernel combos, and none produced the
previ
On Sun, 2013-12-08 at 15:40 -0500, Len Brown wrote:
> > FWIW, my little x3550 (E5620) box is spending ~99% of its time in C3 per
> > powertop, deepest state it has.
>
> Please run turbostat, which always describes what the hardware does.
> Depending on the version of powertop and the hardware inv
> FWIW, my little x3550 (E5620) box is spending ~99% of its time in C3 per
> powertop, deepest state it has.
Please run turbostat, which always describes what the hardware does.
Depending on the version of powertop and the hardware involved,
it may be describing that the OS requested -- which is n
On Sat, 2013-12-07 at 03:00 -0500, Len Brown wrote:
> Hello Thomas,
>
> An idle WSM-EX box (40 Xeon cores) runs 50 Watts hotter after this patch:
>
> commit 7d1a941731fabf27e5fb6edbebb79fe856edb4e5
> Author: Thomas Gleixner
> Date: Thu Mar 21 22:50:03 2013 +0100
>
> x86: Use generic idle
On Sat, 2013-12-07 at 11:45 -0500, Len Brown wrote:
> >> It fixes that, except for my Q6600 box. Too bad mwait_idle() went away,
> >> beloved old box doesn't play hints game, so it continues to flog itself.
>
>
> Thanks for pointing this out, Mike!
>
> A Q6600 is a Kentsfield. I dug one of th
>> It fixes that, except for my Q6600 box. Too bad mwait_idle() went away,
>> beloved old box doesn't play hints game, so it continues to flog itself.
Thanks for pointing this out, Mike!
A Q6600 is a Kentsfield. I dug one of those up.
Indeed, the only idle capabilities it has are HALT
and old
On Sat, Dec 7, 2013 at 3:39 AM, Mike Galbraith wrote:
> On Sat, 2013-12-07 at 03:00 -0500, Len Brown wrote:
>
>> No, Linux-3.13-rc3 does not fix this issue, even though it contains
>> the following patch, claiming to address an issue with the commit above:
>>
>> commit ea8117478918a4734586d35ff530
Len,
On Sat, 7 Dec 2013, Len Brown wrote:
>
> How shall we proceed?
Can you please gather a function trace so I can see what the system is
doing? Preferrably with 3.13-rc3 so we have Peters fix included.
Please send it offlist or put it somehwere for download.
Thanks,
tglx
--
To unsubs
On Sat, 2013-12-07 at 03:00 -0500, Len Brown wrote:
> No, Linux-3.13-rc3 does not fix this issue, even though it contains
> the following patch, claiming to address an issue with the commit above:
>
> commit ea8117478918a4734586d35ff530721b682425be
> Author: Peter Zijlstra
> Date: Wed Sep 11 1
Hello Thomas,
An idle WSM-EX box (40 Xeon cores) runs 50 Watts hotter after this patch:
commit 7d1a941731fabf27e5fb6edbebb79fe856edb4e5
Author: Thomas Gleixner
Date: Thu Mar 21 22:50:03 2013 +0100
x86: Use generic idle loop
ie. the commit before this patch (aba92c9e2cf3042bf6efc68fa2e423
51 matches
Mail list logo
