[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150513085824.7bd2d788@redhat.com>
Date: Wed, 13 May 2015 08:58:24 -0400
From: Luiz Capitulino <lcapitulino@...hat.com>
To: Sasha Levin <sasha.levin@...cle.com>
Cc: KVM General <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, mtosatti@...hat.com,
Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: kvm: odd time values since "kvmclock: set scheduler clock
stable"
On Tue, 12 May 2015 19:17:24 -0400
Sasha Levin <sasha.levin@...cle.com> wrote:
> Hi all,
>
> I'm seeing odd jump in time values during boot of a KVM guest:
>
> [...]
> [ 0.000000] tsc: Detected 2260.998 MHz processor
> [3376355.247558] Calibrating delay loop (skipped) preset value..
> [...]
>
> I've bisected it to:
Thanks for bisecting. You just boot a guest to reproduce this? How
many vCPUs does the guest have?
Paolo, I think it's better to drop this patch for now.
>
>
> commit ff7bbb9c6ab6e6620429daeff39424bbde1a94b4
> Author: Luiz Capitulino <lcapitulino@...hat.com>
> Date: Thu Apr 23 17:12:42 2015 -0400
>
> kvmclock: set scheduler clock stable
>
> If you try to enable NOHZ_FULL on a guest today, you'll get
> the following error when the guest tries to deactivate the
> scheduler tick:
>
> WARNING: CPU: 3 PID: 2182 at kernel/time/tick-sched.c:192 can_stop_full_tick+0xb9/0x290()
> NO_HZ FULL will not work with unstable sched clock
> CPU: 3 PID: 2182 Comm: kworker/3:1 Not tainted 4.0.0-10545-gb9bb6fb #204
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> Workqueue: events flush_to_ldisc
> ffffffff8162a0c7 ffff88011f583e88 ffffffff814e6ba0 0000000000000002
> ffff88011f583ed8 ffff88011f583ec8 ffffffff8104d095 ffff88011f583eb8
> 0000000000000000 0000000000000003 0000000000000001 0000000000000001
> Call Trace:
> <IRQ> [<ffffffff814e6ba0>] dump_stack+0x4f/0x7b
> [<ffffffff8104d095>] warn_slowpath_common+0x85/0xc0
> [<ffffffff8104d146>] warn_slowpath_fmt+0x46/0x50
> [<ffffffff810bd2a9>] can_stop_full_tick+0xb9/0x290
> [<ffffffff810bd9ed>] tick_nohz_irq_exit+0x8d/0xb0
> [<ffffffff810511c5>] irq_exit+0xc5/0x130
> [<ffffffff814f180a>] smp_apic_timer_interrupt+0x4a/0x60
> [<ffffffff814eff5e>] apic_timer_interrupt+0x6e/0x80
> <EOI> [<ffffffff814ee5d1>] ? _raw_spin_unlock_irqrestore+0x31/0x60
> [<ffffffff8108bbc8>] __wake_up+0x48/0x60
> [<ffffffff8134836c>] n_tty_receive_buf_common+0x49c/0xba0
> [<ffffffff8134a6bf>] ? tty_ldisc_ref+0x1f/0x70
> [<ffffffff81348a84>] n_tty_receive_buf2+0x14/0x20
> [<ffffffff8134b390>] flush_to_ldisc+0xe0/0x120
> [<ffffffff81064d05>] process_one_work+0x1d5/0x540
> [<ffffffff81064c81>] ? process_one_work+0x151/0x540
> [<ffffffff81065191>] worker_thread+0x121/0x470
> [<ffffffff81065070>] ? process_one_work+0x540/0x540
> [<ffffffff8106b4df>] kthread+0xef/0x110
> [<ffffffff8106b3f0>] ? __kthread_parkme+0xa0/0xa0
> [<ffffffff814ef4f2>] ret_from_fork+0x42/0x70
> [<ffffffff8106b3f0>] ? __kthread_parkme+0xa0/0xa0
> ---[ end trace 06e3507544a38866 ]---
>
> However, it turns out that kvmclock does provide a stable
> sched_clock callback. So, let the scheduler know this which
> in turn makes NOHZ_FULL work in the guest.
>
> Signed-off-by: Marcelo Tosatti <mtosatti@...hat.com>
> Signed-off-by: Luiz Capitulino <lcapitulino@...hat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
>
>
> Thanks,
> Sasha
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists