* 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.
> >
> > D
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,
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: sched
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 fin
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 linux
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 li
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 q
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 tha
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 t
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 mat
>
> 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 li
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 h
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 id
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
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
> Author:
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 [m
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 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
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 im
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]
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: colou
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 duri
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 in
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 n
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
33 matches
Mail list logo
