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
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
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
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 bitbuc...@online.de 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:
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 patch in the
* Peter Zijlstra pet...@infradead.org 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
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.
So no, I don't
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 need to write
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,
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
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 ---
>> >
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
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
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
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
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
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
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
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,
* 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
* 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.
* 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
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
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
* 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
* 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
* 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
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
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
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
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
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:
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
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
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
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 erratum
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:
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 set
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 for models
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 is really
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
* Peter Zijlstra pet...@infradead.org 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
* Borislav Petkov b...@alien8.de 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
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 modification to
* Thomas Gleixner t...@linutronix.de 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
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
On Wed, Dec 11, 2013 at 03:56:55PM +0100, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de 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: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 before
On Wed, Dec 11, 2013 at 04:09:11PM +0100, Ingo Molnar wrote:
* Thomas Gleixner t...@linutronix.de 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
* Peter Zijlstra pet...@infradead.org 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
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Dec 11, 2013 at 04:09:11PM +0100, Ingo Molnar wrote:
* Thomas Gleixner t...@linutronix.de wrote:
On Wed, 11 Dec 2013, Ingo Molnar wrote:
Another thing that is required I think is to issue a write barrier
before
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Dec 11, 2013 at 03:56:55PM +0100, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de 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
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,
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
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 same
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
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 wakeup.
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 all. It
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 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 deletions(-)
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 deletions(-)
As in it hangs at that point?
Mike Galbraith bitbuc...@online.de 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 ---
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
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, continents
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
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
* 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
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
* 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
* 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!
> >
>
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 0.23
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
* Mike Galbraith bitbuc...@online.de 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!
* Mike Galbraith bitbuc...@online.de 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
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
* Thomas Gleixner t...@linutronix.de 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
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
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
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
> 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
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
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 involved,
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
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
>> 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
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
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
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
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
Hello Thomas,
An idle WSM-EX box (40 Xeon cores) runs 50 Watts hotter after this patch:
commit 7d1a941731fabf27e5fb6edbebb79fe856edb4e5
Author: Thomas Gleixner t...@linutronix.de
Date: Thu Mar 21 22:50:03 2013 +0100
x86: Use generic idle loop
ie. the commit before this patch
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 pet...@infradead.org
Date:
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
On Sat, Dec 7, 2013 at 3:39 AM, Mike Galbraith bitbuc...@online.de 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
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
1 - 100 of 102 matches
Mail list logo
