[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7b182c01-5d17-d73a-1906-3f7155b4236c@redhat.com>
Date: Tue, 7 Jun 2016 14:34:36 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Wanpeng Li <kernellwp@...il.com>
Cc: Wanpeng Li <wanpeng.li@...mail.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Rik van Riel <riel@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Frederic Weisbecker <fweisbec@...il.com>,
Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: [PATCH v4 3/3] sched/cputime: Add steal time support to full
dynticks CPU time accounting
On 07/06/2016 14:15, Wanpeng Li wrote:
>> >
>> > You're adding almost the same code to two callers of get_vtime_delta out
>> > of three. I don't know the vtime accounting code very well, but why
>> > doesn't the same apply to account_idle_time?
> St stuff is accounted when vCPUs(tasks on host) are enqueued in rb
> trees of pCPUs, which means that they are ready to run until they
> finially reach CPUs. However, when vCPUs are idle, they will be
> dequeued from rb trees and the time will be not accounted as st.
Why not? If idle=poll, for example, any time the guest is suspended
(and thus cannot poll) does count as stolen time.
In addition, you are going to account the stolen time anyway sooner or
later, and then it will be accounted wrong (subtracted to either user or
system time). I really believe you should do the change directly in
get_vtime_delta.
Paolo
>> > If it does, you should instead change get_vtime_delta to process steal
>> > time and subtract it from the result.
>> >
>> > Secondarily, when can it happen that steal_time > delta_time?
> Rik explanation it when he reply to v1.
> http://www.gossamer-threads.com/lists/linux/kernel/2441175?do=post_view_threaded#2441175
Powered by blists - more mailing lists