[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANRm+CzF5RLS=yLp7xJqkUG3HO4R-xUxGsOeZUBHj8gyEiD5gA@mail.gmail.com>
Date: Mon, 15 Aug 2016 16:53:49 +0800
From: Wanpeng Li <kernellwp@...il.com>
To: Rik van Riel <riel@...hat.com>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Wanpeng Li <wanpeng.li@...mail.com>,
Thomas Gleixner <tglx@...utronix.de>,
Radim Krcmar <rkrcmar@...hat.com>,
Mike Galbraith <efault@....de>
Subject: Re: [PATCH] time,virt: resync steal time when guest & host lose sync
2016-08-12 23:58 GMT+08:00 Rik van Riel <riel@...hat.com>:
[...]
> Wanpeng, does the patch below work for you?
It will break steal time for full dynticks guest, and there is a
calltrace of thread_group_cputime_adjusted call stack, RIP is
cputime_adjust+0xff/0x130.
>
> Everybody else, does this patch look acceptable?
>
> ---8<---
> Subject: time,virt: do not limit steal_account_process_time
>
> When a guest is interrupted for a longer amount of time, missed clock
> ticks are not redelivered later. Because of that, we should not limit
Interesting, so do we need to add a feature like lapic timer
interrrupt coalescing in kvm? There is a RTC interrupt coalescing in
qemu to handle the scenario you mentioned for windows guest, if we
need a similar feature for linux guest? Paolo, Radim? I can try it if
you think it's valuable. :)
Regards,
Wanpeng Li
Powered by blists - more mailing lists