Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1461608 > unrolled thread

Re: [PATCH] time,virt: resync steal time when guest & host lose sync

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] time,virt: resync steal time when guest & host lose sync Ingo Molnar <mingo@kernel.org> - 2016-08-13 10:50 +0200
    Re: [PATCH] time,virt: resync steal time when guest & host lose sync Rik van Riel <riel@redhat.com> - 2016-08-14 11:00 +0200
    Re: [PATCH] time,virt: resync steal time when guest & host lose sync Wanpeng Li <kernellwp@gmail.com> - 2016-08-18 10:40 +0200

#1461608 — Re: [PATCH] time,virt: resync steal time when guest & host lose sync

* Rik van Riel <riel@redhat.com> wrote:

> On Wed, 10 Aug 2016 07:39:08 +0800
> Wanpeng Li <kernellwp@gmail.com> wrote:
> 
> > The regression is caused by your commit "sched,time: Count actually
> > elapsed irq & softirq time".
> 
> Wanpeng, does this patch fix your issue?
> 
> Paolo, what is your opinion on this issue?
> 
> I can think of all kinds of ways in which guest and host might lose
> sync with steal time, from uninitialized values at boot, to guest
> pause, followed by save to disk, and reload, to live migration, to...
> 
> ---8<---
> 
> Subject: time,virt: resync steal time when guest & host lose sync
> 
> When guest and host wildly disagree on steal time, a guest can
> do several things:
> 1) Quickly account all the steal time at once (the kernel did this before
>    57430218317e ("sched/cputime: Count actually elapsed irq & softirq time"),
>    when steal_account_process_ticks got ULONG_MAX as its maximum value.
> 2) Stay out of sync for an indeterminate amount of time. This is what the
>    system does today.
> 3) Sync up the guest value to the host-provided value, without accounting
>    an absurdly large value in the cpu time statistics.
> 
> This patch makes the kernel do (3), which seems like the right thing
> to do.
> 
> The exact value of the threshold use probably does not matter too much,
> as long as it is long enough to cover all the timer ticks that passed
> during an idle period, because (irqtime_)account_idle_ticks can process
> a large amount of time all at once.
> 
> Signed-off-by: Rik van Riel <riel@redhat.com>
> Reported-by: Wanpeng Li <kernellwp@gmail.com>
> ---
>  kernel/sched/cputime.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)

fails to build on x86 allnoconfig:

  kernel/sched/cputime.c:524:10: error: too many arguments to function ‘steal_account_process_time’

Thanks,

	Ingo

[toc] | [next] | [standalone]

#1461724

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2016-08-13 at 10:42 +0200, Ingo Molnar wrote:
> * Rik van Riel <riel@redhat.com> wrote:
> 
> > On Wed, 10 Aug 2016 07:39:08 +0800
> > Wanpeng Li <kernellwp@gmail.com> wrote:
> > 
> > > The regression is caused by your commit "sched,time: Count
> > > actually
> > > elapsed irq & softirq time".
> > 
> > Wanpeng, does this patch fix your issue?
> > 
> > Paolo, what is your opinion on this issue?
> > 
> > I can think of all kinds of ways in which guest and host might lose
> > sync with steal time, from uninitialized values at boot, to guest
> > pause, followed by save to disk, and reload, to live migration,
> > to...
> > 
> > ---8<---
> > 
> > Subject: time,virt: resync steal time when guest & host lose sync
> > 
> > When guest and host wildly disagree on steal time, a guest can
> > do several things:
> > 1) Quickly account all the steal time at once (the kernel did this
> > before
> >    57430218317e ("sched/cputime: Count actually elapsed irq &
> > softirq time"),
> >    when steal_account_process_ticks got ULONG_MAX as its maximum
> > value.
> > 2) Stay out of sync for an indeterminate amount of time. This is
> > what the
> >    system does today.
> > 3) Sync up the guest value to the host-provided value, without
> > accounting
> >    an absurdly large value in the cpu time statistics.
> > 
> > This patch makes the kernel do (3), which seems like the right
> > thing
> > to do.
> > 
> > The exact value of the threshold use probably does not matter too
> > much,
> > as long as it is long enough to cover all the timer ticks that
> > passed
> > during an idle period, because (irqtime_)account_idle_ticks can
> > process
> > a large amount of time all at once.
> > 
> > Signed-off-by: Rik van Riel <riel@redhat.com>
> > Reported-by: Wanpeng Li <kernellwp@gmail.com>
> > ---
> >  kernel/sched/cputime.c | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> fails to build on x86 allnoconfig:
> 
>   kernel/sched/cputime.c:524:10: error: too many arguments to
> function ‘steal_account_process_time’

Which patch did you apply?  The subject and comment
of the email suggest you tried applying the one
Paolo and Frederic objected to.

The compile error suggest you applied the patch with the
subject "time,virt: do not limit steal_account_process_time"

In that case, did you apply Wanpeng's patch that adds an
additional call site for steal_account_process_time?

I do not have that patch in my tree yet, and one additional
line of change will be needed.

-- 

All Rights Reversed.

[toc] | [prev] | [next] | [standalone]

#1464994

2016-08-13 16:42 GMT+08:00 Ingo Molnar <mingo@kernel.org>:
>
> * Rik van Riel <riel@redhat.com> wrote:
>
>> On Wed, 10 Aug 2016 07:39:08 +0800
>> Wanpeng Li <kernellwp@gmail.com> wrote:
>>
>> > The regression is caused by your commit "sched,time: Count actually
>> > elapsed irq & softirq time".
>>
>> Wanpeng, does this patch fix your issue?
>>
>> Paolo, what is your opinion on this issue?
>>
>> I can think of all kinds of ways in which guest and host might lose
>> sync with steal time, from uninitialized values at boot, to guest
>> pause, followed by save to disk, and reload, to live migration, to...
>>
>> ---8<---
>>
>> Subject: time,virt: resync steal time when guest & host lose sync
>>
>> When guest and host wildly disagree on steal time, a guest can
>> do several things:
>> 1) Quickly account all the steal time at once (the kernel did this before
>>    57430218317e ("sched/cputime: Count actually elapsed irq & softirq time"),
>>    when steal_account_process_ticks got ULONG_MAX as its maximum value.
>> 2) Stay out of sync for an indeterminate amount of time. This is what the
>>    system does today.
>> 3) Sync up the guest value to the host-provided value, without accounting
>>    an absurdly large value in the cpu time statistics.
>>
>> This patch makes the kernel do (3), which seems like the right thing
>> to do.
>>
>> The exact value of the threshold use probably does not matter too much,
>> as long as it is long enough to cover all the timer ticks that passed
>> during an idle period, because (irqtime_)account_idle_ticks can process
>> a large amount of time all at once.
>>
>> Signed-off-by: Rik van Riel <riel@redhat.com>
>> Reported-by: Wanpeng Li <kernellwp@gmail.com>
>> ---
>>  kernel/sched/cputime.c | 12 +++++++++++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> fails to build on x86 allnoconfig:
>
>   kernel/sched/cputime.c:524:10: error: too many arguments to function ‘steal_account_process_time’

Please try this one. https://lkml.org/lkml/2016/8/16/931

Regards,
Wanpeng Li

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web