* Dave Young wrote:
> On 01/23/14 at 05:56pm, Peter Zijlstra wrote:
> > On Thu, Jan 23, 2014 at 10:10:28AM +0800, Dave Young wrote:
> > > Hmm, seems the my physical machine is booting fine with this patch. kvm
> > > guest problem still exist, but that kvm thing might be other problem.
> >
> >
On 01/23/14 at 05:56pm, Peter Zijlstra wrote:
> On Thu, Jan 23, 2014 at 10:10:28AM +0800, Dave Young wrote:
> > Hmm, seems the my physical machine is booting fine with this patch. kvm
> > guest problem still exist, but that kvm thing might be other problem.
>
> Dave, could you try with
On Thu, Jan 23, 2014 at 10:10:28AM +0800, Dave Young wrote:
> Hmm, seems the my physical machine is booting fine with this patch. kvm
> guest problem still exist, but that kvm thing might be other problem.
Dave, could you try with tip/master, Ingo pushed out all the fixes
gathered.
Lacking that,
On Thu, Jan 23, 2014 at 4:48 AM, Peter Zijlstra wrote:
> On Wed, Jan 22, 2014 at 10:17:40PM +0100, Markus Trippelsdorf wrote:
>> Yes. Thanks Peter.
>>
>
> Ah much simpler patch that should have the same effect:
This fixes the issue on my baremetal i7 machine as well.
josh
> ---
> Subject:
On Thu, Jan 23, 2014 at 11:01:00AM +0100, Markus Trippelsdorf wrote:
> On 2014.01.23 at 10:48 +0100, Peter Zijlstra wrote:
> > On Wed, Jan 22, 2014 at 10:17:40PM +0100, Markus Trippelsdorf wrote:
> >
> > Ah much simpler patch that should have the same effect:
>
> Yes. FWIW it also seems to be
On 2014.01.23 at 10:48 +0100, Peter Zijlstra wrote:
> On Wed, Jan 22, 2014 at 10:17:40PM +0100, Markus Trippelsdorf wrote:
>
> Ah much simpler patch that should have the same effect:
Yes. FWIW it also seems to be fine.
--
Markus
--
To unsubscribe from this list: send the line "unsubscribe
On Wed, Jan 22, 2014 at 10:17:40PM +0100, Markus Trippelsdorf wrote:
> Yes. Thanks Peter.
>
Ah much simpler patch that should have the same effect:
---
Subject: sched/x86/tsc: Initialize multiplier to 0
From: Peter Zijlstra
Date: Wed, 22 Jan 2014 22:08:14 +0100
Since we keep the clock value
On Wed, Jan 22, 2014 at 10:17:40PM +0100, Markus Trippelsdorf wrote:
Yes. Thanks Peter.
Ah much simpler patch that should have the same effect:
---
Subject: sched/x86/tsc: Initialize multiplier to 0
From: Peter Zijlstra pet...@infradead.org
Date: Wed, 22 Jan 2014 22:08:14 +0100
Since we keep
On 2014.01.23 at 10:48 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 10:17:40PM +0100, Markus Trippelsdorf wrote:
Ah much simpler patch that should have the same effect:
Yes. FWIW it also seems to be fine.
--
Markus
--
To unsubscribe from this list: send the line unsubscribe
On Thu, Jan 23, 2014 at 11:01:00AM +0100, Markus Trippelsdorf wrote:
On 2014.01.23 at 10:48 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 10:17:40PM +0100, Markus Trippelsdorf wrote:
Ah much simpler patch that should have the same effect:
Yes. FWIW it also seems to be fine.
On Thu, Jan 23, 2014 at 4:48 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Jan 22, 2014 at 10:17:40PM +0100, Markus Trippelsdorf wrote:
Yes. Thanks Peter.
Ah much simpler patch that should have the same effect:
This fixes the issue on my baremetal i7 machine as well.
josh
---
On Thu, Jan 23, 2014 at 10:10:28AM +0800, Dave Young wrote:
Hmm, seems the my physical machine is booting fine with this patch. kvm
guest problem still exist, but that kvm thing might be other problem.
Dave, could you try with tip/master, Ingo pushed out all the fixes
gathered.
Lacking that,
On 01/23/14 at 05:56pm, Peter Zijlstra wrote:
On Thu, Jan 23, 2014 at 10:10:28AM +0800, Dave Young wrote:
Hmm, seems the my physical machine is booting fine with this patch. kvm
guest problem still exist, but that kvm thing might be other problem.
Dave, could you try with tip/master, Ingo
* Dave Young dyo...@redhat.com wrote:
On 01/23/14 at 05:56pm, Peter Zijlstra wrote:
On Thu, Jan 23, 2014 at 10:10:28AM +0800, Dave Young wrote:
Hmm, seems the my physical machine is booting fine with this patch. kvm
guest problem still exist, but that kvm thing might be other problem.
On 01/23/14 at 09:53am, Dave Young wrote:
> On 01/22/14 at 10:08pm, Peter Zijlstra wrote:
> > >
> > > I think its the right region to look through. My current suspect is the
> > > linear continuity fit with the initial 'random' multiplier.
> > >
> > > That initial 'random' multiplier can get us
On 01/22/14 at 10:08pm, Peter Zijlstra wrote:
> >
> > I think its the right region to look through. My current suspect is the
> > linear continuity fit with the initial 'random' multiplier.
> >
> > That initial 'random' multiplier can get us quite high, and we'll fit
> > the function to match
On 01/22/14 at 12:59pm, Peter Zijlstra wrote:
> On Wed, Jan 22, 2014 at 11:45:32AM +0100, Peter Zijlstra wrote:
> > Ho humm.
>
> OK, so I had me a ponder; does the below fix things for you and David?
> I've only done a boot test on real proper hardware :-)
>
> ---
> kernel/sched/clock.c | 42
On Wed, Jan 22, 2014 at 4:08 PM, Peter Zijlstra wrote:
>>
>> I think its the right region to look through. My current suspect is the
>> linear continuity fit with the initial 'random' multiplier.
>>
>> That initial 'random' multiplier can get us quite high, and we'll fit
>> the function to match
On 01/22/2014 12:14 PM, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 05:28:37PM -0500, Sasha Levin wrote:
[0.00] Initmem setup node 30 [mem 0x12ee00-0x138dff]
[0.00] NODE_DATA [mem 0xcfa42000-0xcfa72fff]
[0.00] NODE_DATA(30) on node
On 2014.01.22 at 22:08 +0100, Peter Zijlstra wrote:
> >
> > I think its the right region to look through. My current suspect is the
> > linear continuity fit with the initial 'random' multiplier.
> >
> > That initial 'random' multiplier can get us quite high, and we'll fit
> > the function to
>
> I think its the right region to look through. My current suspect is the
> linear continuity fit with the initial 'random' multiplier.
>
> That initial 'random' multiplier can get us quite high, and we'll fit
> the function to match that but continue at a sane rate.
>
> I'll try and prod a
On Wed, Jan 22, 2014 at 08:12:54PM +0100, Markus Trippelsdorf wrote:
> On 2014.01.22 at 20:09 +0100, Markus Trippelsdorf wrote:
> > On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
> > > On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
> > >
> > > > >FYI it happens on real
On Wed, Jan 22, 2014 at 1:45 PM, Markus Trippelsdorf
wrote:
> On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
>> On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
>>
>> > >FYI it happens on real hardware on my machine:
>>
>> > >[ 60.375384] process: using AMD E400 aware
On 2014.01.22 at 20:09 +0100, Markus Trippelsdorf wrote:
> On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
> > On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
> >
> > > >FYI it happens on real hardware on my machine:
> >
> > > >[ 60.375384] process: using AMD E400
On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
> On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
>
> > >FYI it happens on real hardware on my machine:
>
> > >[ 60.375384] process: using AMD E400 aware idle routine
>
> > But this is a different issue. I've bisected it
On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
> On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
>
> > >FYI it happens on real hardware on my machine:
>
> > >[ 60.375384] process: using AMD E400 aware idle routine
>
> > But this is a different issue. I've bisected it
On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
> >FYI it happens on real hardware on my machine:
> >[ 60.375384] process: using AMD E400 aware idle routine
> But this is a different issue. I've bisected it to:
>
> commit 20d1c86a57762f0a33a78988e3fc8818316badd4
>
On 2014.01.22 at 09:26 -0500, Sasha Levin wrote:
> On 01/22/2014 08:14 AM, Markus Trippelsdorf wrote:
> > On 2014.01.22 at 13:30 +0100, Peter Zijlstra wrote:
> >> >On Wed, Jan 22, 2014 at 01:26:09PM +0100, Markus Trippelsdorf wrote:
> >>> > >On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
>
On Tue, Jan 21, 2014 at 05:28:37PM -0500, Sasha Levin wrote:
> [0.00] Initmem setup node 30 [mem 0x12ee00-0x138dff]
> [0.00] NODE_DATA [mem 0xcfa42000-0xcfa72fff]
> [0.00] NODE_DATA(30) on node 1
> [0.00] Initmem setup node 31
On 01/22/2014 08:14 AM, Markus Trippelsdorf wrote:
On 2014.01.22 at 13:30 +0100, Peter Zijlstra wrote:
>On Wed, Jan 22, 2014 at 01:26:09PM +0100, Markus Trippelsdorf wrote:
> >On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
> > >On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus
On 2014.01.22 at 13:30 +0100, Peter Zijlstra wrote:
> On Wed, Jan 22, 2014 at 01:26:09PM +0100, Markus Trippelsdorf wrote:
> > On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
> > > On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
> > > > FYI it happens on real hardware on
On Wed, Jan 22, 2014 at 01:26:09PM +0100, Markus Trippelsdorf wrote:
> On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
> > On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
> > > FYI it happens on real hardware on my machine:
> > > ...
> > > [0.00] Hierarchical RCU
On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
> On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
> > FYI it happens on real hardware on my machine:
> > ...
> > [0.00] Hierarchical RCU implementation.
> > [0.00] NR_IRQS:4352 nr_irqs:712 16
> > [
On Wed, Jan 22, 2014 at 01:07:57PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
> > FYI it happens on real hardware on my machine:
> > ...
> > [0.00] Hierarchical RCU implementation.
> > [0.00] NR_IRQS:4352 nr_irqs:712 16
> > [
On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
> FYI it happens on real hardware on my machine:
> ...
> [0.00] Hierarchical RCU implementation.
> [0.00] NR_IRQS:4352 nr_irqs:712 16
> [0.00] spurious 8259A interrupt: IRQ7.
> [0.00] Console:
On 2014.01.22 at 11:45 +0100, Peter Zijlstra wrote:
> On Tue, Jan 21, 2014 at 05:28:37PM -0500, Sasha Levin wrote:
> > On 12/12/2013 09:08 AM, Peter Zijlstra wrote:
> >
> > This patch seems to be causing an issue with booting a KVM guest. It seems
> > that it
> > causes the time to go random
On Wed, Jan 22, 2014 at 11:45:32AM +0100, Peter Zijlstra wrote:
> Ho humm.
OK, so I had me a ponder; does the below fix things for you and David?
I've only done a boot test on real proper hardware :-)
---
kernel/sched/clock.c | 42 +-
1 file changed, 33
On Tue, Jan 21, 2014 at 05:28:37PM -0500, Sasha Levin wrote:
> On 12/12/2013 09:08 AM, Peter Zijlstra wrote:
>
> This patch seems to be causing an issue with booting a KVM guest. It seems
> that it
> causes the time to go random during early boot process:
>
> [0.00] Initmem setup
On Tue, Jan 21, 2014 at 05:28:37PM -0500, Sasha Levin wrote:
On 12/12/2013 09:08 AM, Peter Zijlstra wrote:
This patch seems to be causing an issue with booting a KVM guest. It seems
that it
causes the time to go random during early boot process:
[0.00] Initmem setup node 30
On Wed, Jan 22, 2014 at 11:45:32AM +0100, Peter Zijlstra wrote:
Ho humm.
OK, so I had me a ponder; does the below fix things for you and David?
I've only done a boot test on real proper hardware :-)
---
kernel/sched/clock.c | 42 +-
1 file changed, 33
On 2014.01.22 at 11:45 +0100, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 05:28:37PM -0500, Sasha Levin wrote:
On 12/12/2013 09:08 AM, Peter Zijlstra wrote:
This patch seems to be causing an issue with booting a KVM guest. It seems
that it
causes the time to go random during early
On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
...
[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS:4352 nr_irqs:712 16
[0.00] spurious 8259A interrupt: IRQ7.
[0.00] Console: colour
On Wed, Jan 22, 2014 at 01:07:57PM +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
...
[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS:4352 nr_irqs:712 16
[
On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
...
[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS:4352 nr_irqs:712 16
[0.00] spurious
On Wed, Jan 22, 2014 at 01:26:09PM +0100, Markus Trippelsdorf wrote:
On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
...
[0.00] Hierarchical RCU
On 2014.01.22 at 13:30 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 01:26:09PM +0100, Markus Trippelsdorf wrote:
On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
On 01/22/2014 08:14 AM, Markus Trippelsdorf wrote:
On 2014.01.22 at 13:30 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 01:26:09PM +0100, Markus Trippelsdorf wrote:
On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 01:00:48PM +0100, Markus Trippelsdorf
On Tue, Jan 21, 2014 at 05:28:37PM -0500, Sasha Levin wrote:
[0.00] Initmem setup node 30 [mem 0x12ee00-0x138dff]
[0.00] NODE_DATA [mem 0xcfa42000-0xcfa72fff]
[0.00] NODE_DATA(30) on node 1
[0.00] Initmem setup node 31 [mem
On 2014.01.22 at 09:26 -0500, Sasha Levin wrote:
On 01/22/2014 08:14 AM, Markus Trippelsdorf wrote:
On 2014.01.22 at 13:30 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 01:26:09PM +0100, Markus Trippelsdorf wrote:
On 2014.01.22 at 13:07 +0100, Peter Zijlstra wrote:
On Wed, Jan
On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
[ 60.375384] process: using AMD E400 aware idle routine
But this is a different issue. I've bisected it to:
commit 20d1c86a57762f0a33a78988e3fc8818316badd4
Author: Peter
On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
[ 60.375384] process: using AMD E400 aware idle routine
But this is a different issue. I've bisected it to:
On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
[ 60.375384] process: using AMD E400 aware idle routine
But this is a different issue. I've bisected it to:
On 2014.01.22 at 20:09 +0100, Markus Trippelsdorf wrote:
On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
[ 60.375384] process: using AMD E400 aware idle routine
On Wed, Jan 22, 2014 at 1:45 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my machine:
[ 60.375384] process: using AMD E400
On Wed, Jan 22, 2014 at 08:12:54PM +0100, Markus Trippelsdorf wrote:
On 2014.01.22 at 20:09 +0100, Markus Trippelsdorf wrote:
On 2014.01.22 at 19:42 +0100, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 07:35:38PM +0100, Markus Trippelsdorf wrote:
FYI it happens on real hardware on my
I think its the right region to look through. My current suspect is the
linear continuity fit with the initial 'random' multiplier.
That initial 'random' multiplier can get us quite high, and we'll fit
the function to match that but continue at a sane rate.
I'll try and prod a little
On 2014.01.22 at 22:08 +0100, Peter Zijlstra wrote:
I think its the right region to look through. My current suspect is the
linear continuity fit with the initial 'random' multiplier.
That initial 'random' multiplier can get us quite high, and we'll fit
the function to match that but
On 01/22/2014 12:14 PM, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 05:28:37PM -0500, Sasha Levin wrote:
[0.00] Initmem setup node 30 [mem 0x12ee00-0x138dff]
[0.00] NODE_DATA [mem 0xcfa42000-0xcfa72fff]
[0.00] NODE_DATA(30) on node
On Wed, Jan 22, 2014 at 4:08 PM, Peter Zijlstra pet...@infradead.org wrote:
I think its the right region to look through. My current suspect is the
linear continuity fit with the initial 'random' multiplier.
That initial 'random' multiplier can get us quite high, and we'll fit
the function
On 01/22/14 at 12:59pm, Peter Zijlstra wrote:
On Wed, Jan 22, 2014 at 11:45:32AM +0100, Peter Zijlstra wrote:
Ho humm.
OK, so I had me a ponder; does the below fix things for you and David?
I've only done a boot test on real proper hardware :-)
---
kernel/sched/clock.c | 42
On 01/22/14 at 10:08pm, Peter Zijlstra wrote:
I think its the right region to look through. My current suspect is the
linear continuity fit with the initial 'random' multiplier.
That initial 'random' multiplier can get us quite high, and we'll fit
the function to match that but
On 01/23/14 at 09:53am, Dave Young wrote:
On 01/22/14 at 10:08pm, Peter Zijlstra wrote:
I think its the right region to look through. My current suspect is the
linear continuity fit with the initial 'random' multiplier.
That initial 'random' multiplier can get us quite high, and
On 12/12/2013 09:08 AM, Peter Zijlstra wrote:
In order to avoid the runtime condition and variable load turn
sched_clock_stable into a static_key.
Also provide a shorter implementation of local_clock() and
cpu_clock(int) when sched_clock_stable==1.
MAINLINE PRE
On 12/12/2013 09:08 AM, Peter Zijlstra wrote:
In order to avoid the runtime condition and variable load turn
sched_clock_stable into a static_key.
Also provide a shorter implementation of local_clock() and
cpu_clock(int) when sched_clock_stable==1.
MAINLINE PRE
In order to avoid the runtime condition and variable load turn
sched_clock_stable into a static_key.
Also provide a shorter implementation of local_clock() and
cpu_clock(int) when sched_clock_stable==1.
MAINLINE PRE POST
sched_clock_stable: 1 1
In order to avoid the runtime condition and variable load turn
sched_clock_stable into a static_key.
Also provide a shorter implementation of local_clock() and
cpu_clock(int) when sched_clock_stable==1.
MAINLINE PRE POST
sched_clock_stable: 1 1
66 matches
Mail list logo
