On Sat, Oct 10, 2009 at 02:34:22AM +0400, Michael Tokarev wrote:
> Frederic Weisbecker wrote:
>> On Sat, Oct 10, 2009 at 01:22:16AM +0400, Michael Tokarev wrote:
>>> Marcelo Tosatti wrote:
>>> [snip]
>>>
Would be useful to collect sar (sar -B -b -u) output every one second
in both host/gu
On Sat, Oct 10, 2009 at 01:18:16PM +0400, Michael Tokarev wrote:
> Michael Tokarev wrote:
>> Frederic Weisbecker wrote:
> []
> Was there swapping going on?
Not as far as I can see, and sar output agrees.
>>>
>>> But I can read this from you guest traces:
>
> I missed this one yesterday. N
Michael Tokarev wrote:
Frederic Weisbecker wrote:
[]
Was there swapping going on?
Not as far as I can see, and sar output agrees.
But I can read this from you guest traces:
I missed this one yesterday. Note it's GUEST traces
indeed. Higher (read: non-zero) pgp{in,out} and faults
values h
Frederic Weisbecker wrote:
On Sat, Oct 10, 2009 at 01:22:16AM +0400, Michael Tokarev wrote:
Marcelo Tosatti wrote:
[snip]
Would be useful to collect sar (sar -B -b -u) output every one second
in both host/guest. You already mentioned load was low, but this should
give more details.
Here we go
On Sat, Oct 10, 2009 at 01:22:16AM +0400, Michael Tokarev wrote:
> Marcelo Tosatti wrote:
> [snip]
>
>> Would be useful to collect sar (sar -B -b -u) output every one second
>> in both host/guest. You already mentioned load was low, but this should
>> give more details.
>
> Here we go: http://www.
Marcelo Tosatti wrote:
[snip]
Would be useful to collect sar (sar -B -b -u) output every one second
in both host/guest. You already mentioned load was low, but this should
give more details.
Here we go: http://www.corpit.ru/mjt/hrtimer-interrupt-too-slow/
Two incindents - cases when hrtimer:
Thomas Gleixner wrote:
[]
Also it's not clear to me why the problem does only happen with
kvm_clock and not with acpi_pm timer emulation (according to the
reporter) and is restricted to SMP guests.
I just reproduced it with acpi_pm. I explained it already to Marcelo,
the problem is that the is
On Thu, 8 Oct 2009, Marcelo Tosatti wrote:
> On Thu, Oct 08, 2009 at 10:05:01AM +0200, Thomas Gleixner wrote:
> > On Wed, 7 Oct 2009, Marcelo Tosatti wrote:
> > > On Thu, Oct 08, 2009 at 01:17:35AM +0200, Frederic Weisbecker wrote:
> > > What about getting rid of the retry loop, instead? So somethi
On Thu, Oct 08, 2009 at 06:06:39PM +0400, Michael Tokarev wrote:
> Thomas Gleixner wrote:
>> On Thu, 8 Oct 2009, Michael Tokarev wrote:
>>
>>> Thomas Gleixner wrote:
On Thu, 8 Oct 2009, Michael Tokarev wrote:
> Yesterday I was "lucky" enough to actually watch what's
> going on when the
On Thu, Oct 08, 2009 at 10:05:01AM +0200, Thomas Gleixner wrote:
> On Wed, 7 Oct 2009, Marcelo Tosatti wrote:
> > On Thu, Oct 08, 2009 at 01:17:35AM +0200, Frederic Weisbecker wrote:
> > What about getting rid of the retry loop, instead? So something
> > like:
> >
> > - run hrtimer callbacks (once
On Thu, 8 Oct 2009, Michael Tokarev wrote:
> Thomas Gleixner wrote:
> >
> > I'm really missing the big picture here.
> > What means "causes timers to be calculated on the "wrong" CPU etc" ?
> > And what do you consider a "scheduling mistake" ?
>
> From the initial diagnostics by Marcelo:
>
> >
Thomas Gleixner wrote:
On Thu, 8 Oct 2009, Michael Tokarev wrote:
Thomas Gleixner wrote:
On Thu, 8 Oct 2009, Michael Tokarev wrote:
Yesterday I was "lucky" enough to actually watch what's
going on when the delay actually happens.
I run desktop environment on a kvm virtual machine here.
The s
On Thu, 8 Oct 2009, Michael Tokarev wrote:
> Thomas Gleixner wrote:
> > On Thu, 8 Oct 2009, Michael Tokarev wrote:
> > > Yesterday I was "lucky" enough to actually watch what's
> > > going on when the delay actually happens.
> > >
> > > I run desktop environment on a kvm virtual machine here.
> >
Thomas Gleixner wrote:
On Thu, 8 Oct 2009, Michael Tokarev wrote:
Yesterday I was "lucky" enough to actually watch what's
going on when the delay actually happens.
I run desktop environment on a kvm virtual machine here.
The server is on diskless terminal, and the rest, incl.
the window manager
[]
hrtimer: interrupt too slow, forcing clock min delta to 461487495 ns
[]
All that does not make sense anymore in a guest. The hang detection
and warnings, the recalibrations of the min_clock_deltas are completely
wrong in this context.
Not only does it spuriously warn, but the minimum timer i
On Thu, 8 Oct 2009, Michael Tokarev wrote:
> Yesterday I was "lucky" enough to actually watch what's
> going on when the delay actually happens.
>
> I run desktop environment on a kvm virtual machine here.
> The server is on diskless terminal, and the rest, incl.
> the window manager etc, is start
On Wed, 7 Oct 2009, Marcelo Tosatti wrote:
> On Thu, Oct 08, 2009 at 01:17:35AM +0200, Frederic Weisbecker wrote:
> What about getting rid of the retry loop, instead? So something
> like:
>
> - run hrtimer callbacks (once)
> - while (tick_program_event(expires))
> expires = ktime_add_ns(expi
[skip everything]
Yesterday I was "lucky" enough to actually watch what's
going on when the delay actually happens.
I run desktop environment on a kvm virtual machine here.
The server is on diskless terminal, and the rest, incl.
the window manager etc, is started from a VM.
And yesterday, durin
On Thu, Oct 08, 2009 at 01:17:35AM +0200, Frederic Weisbecker wrote:
> (Adding Thomas in Cc)
>
>
> On Sat, Oct 03, 2009 at 08:12:05PM -0300, Marcelo Tosatti wrote:
> > Michael,
> >
> > Can you please give the patch below a try please? (without acpi_pm timer
> > or priority adjustments for the g
(Adding Thomas in Cc)
On Sat, Oct 03, 2009 at 08:12:05PM -0300, Marcelo Tosatti wrote:
> Michael,
>
> Can you please give the patch below a try please? (without acpi_pm timer
> or priority adjustments for the guest).
>
> On Tue, Sep 29, 2009 at 05:12:17PM +0400, Michael Tokarev wrote:
> > Hell
Michael Tokarev wrote:
Marcelo Tosatti wrote:
[]
You should see min_delta_ns increase to a much smaller value,
hopefully in
the 2000-1 range.
That's what I see:
Oct 4 16:13:09 paltus kernel: [boot]
Oct 5 12:35:51 paltus kernel: hrtimer: interrupt too slow, forcing clock min
delta to
On 09/29/2009 03:58 PM, Michael Tokarev wrote:
Avi Kivity wrote:
On 09/29/2009 03:12 PM, Michael Tokarev wrote:
[]
The thing is that after some uptime, kvm
guest prints something like this:
hrtimer: interrupt too slow, forcing clock min delta to 461487495 ns
[]
What happens if you use hpet
Marcelo Tosatti wrote:
[]
You should see min_delta_ns increase to a much smaller value, hopefully in
the 2000-1 range.
That's what I see:
Oct 4 16:13:09 paltus kernel: [boot]
Oct 5 12:35:51 paltus kernel: hrtimer: interrupt too slow, forcing clock min
delta to 1500 ns
Oct 5 12:47:29 pa
On Sun, Oct 04, 2009 at 04:01:02PM +0400, Michael Tokarev wrote:
> Marcelo Tosatti wrote:
>> Michael,
>>
>> Can you please give the patch below a try please? (without acpi_pm
>> timer or priority adjustments for the guest).
>
> Sure. I'll try it out in a hour or two, while I can experiment freely
Marcelo Tosatti wrote:
Michael,
Can you please give the patch below a try please? (without acpi_pm timer
or priority adjustments for the guest).
Sure. I'll try it out in a hour or two, while I can experiment freely because
it's weekend.
But I wonder...
[]
hrtimer: interrupt too slow, forci
Michael,
Can you please give the patch below a try please? (without acpi_pm timer
or priority adjustments for the guest).
On Tue, Sep 29, 2009 at 05:12:17PM +0400, Michael Tokarev wrote:
> Hello.
>
> I'm having quite an.. unusable system here.
> It's not really a regresssion with 0.11.0,
> it wa
Avi Kivity wrote:
On 09/29/2009 03:12 PM, Michael Tokarev wrote:
[]
The thing is that after some uptime, kvm
guest prints something like this:
hrtimer: interrupt too slow, forcing clock min delta to 461487495 ns
[]
What happens if you use hpet or pmtimer as guest clocksource?
For all the g
On 09/29/2009 03:12 PM, Michael Tokarev wrote:
Hello.
I'm having quite an.. unusable system here.
It's not really a regresssion with 0.11.0,
it was something similar before, but with
0.11.0 and/or 2.6.31 it become much worse.
The thing is that after some uptime, kvm
guest prints something like
Hello.
I'm having quite an.. unusable system here.
It's not really a regresssion with 0.11.0,
it was something similar before, but with
0.11.0 and/or 2.6.31 it become much worse.
The thing is that after some uptime, kvm
guest prints something like this:
hrtimer: interrupt too slow, forcing cloc
29 matches
Mail list logo
