[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DF805F3.4030603@redhat.com>
Date: Tue, 14 Jun 2011 22:08:03 -0300
From: Glauber Costa <glommer@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Rik van Riel <riel@...hat.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
Avi Kivity <avi@...hat.com>,
Anthony Liguori <aliguori@...ibm.com>,
Eric B Munson <emunson@...bm.net>
Subject: Re: [PATCH 5/7] KVM-GST: KVM Steal time accounting
On 06/14/2011 07:10 AM, Peter Zijlstra wrote:
> On Mon, 2011-06-13 at 19:31 -0400, Glauber Costa wrote:
>> +static inline int touch_steal_time(int is_idle)
>> +{
>> + u64 steal, st = 0;
>> +
>> + if (static_branch(¶virt_steal_enabled)) {
>> +
>> + steal = paravirt_steal_clock(smp_processor_id());
>> +
>> + steal -= this_rq()->prev_steal_time;
>> + this_rq()->prev_steal_time += steal;
>
> If you move this addition below this test:
>
>> + if (is_idle || (steal< TICK_NSEC))
>> + return 0;
>
> that is, right here, then you don't loose tiny steal deltas and
> subsequent ticks accumulate their steal time until you really
> have a full steal tick to account.
true
> I guess you want something different for the idle case though.
definitely.
>> + while (steal> TICK_NSEC) {
>
> /* really, if we wanted a division we'd have written one */
> asm("" : "+rm" (steal));
Out of curiosity, have we seen any compiler de-optimize it to a
division, or are you just being careful ?
>> + steal -= TICK_NSEC;
>> + st++;
>> + }
>> +
>> + account_steal_time(st);
>> + return 1;
>> + }
>> + return 0;
>> +}
>
>
--
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