linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: cov@codeaurora.org (Christopher Covington)
To: linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH 1/3] arm_arch_timer: introduce arch_timer_stolen_ticks
Date: Thu, 02 May 2013 17:33:29 -0400	[thread overview]
Message-ID: <5182DBA9.9080609@codeaurora.org> (raw)
In-Reply-To: <1367482772.21869.26.camel@zakaz.uk.xensource.com>

Hi Ian,

On 05/02/2013 04:19 AM, Ian Campbell wrote:
> On Wed, 2013-05-01 at 21:36 +0100, Christopher Covington wrote:
>> Hi Stefano,
>>
>> On 05/01/2013 03:27 PM, Stefano Stabellini wrote:
>>> Introduce a function, called arch_timer_stolen_ticks, called from the
>>> arch_timer interrupt handler to account for stolen ticks.
>>
>> [...]
>>
>>> diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
>>> index 7ade91d..30db413 100644
>>> --- a/arch/arm/include/asm/arch_timer.h
>>> +++ b/arch/arm/include/asm/arch_timer.h
>>> @@ -13,6 +13,11 @@
>>>  int arch_timer_of_register(void);
>>>  int arch_timer_sched_clock_init(void);
>>>  
>>> +/* per-platform function to calculate stolen ticks (clock cycles stolen
>>> + * to the vcpu by the hypervisor).

[...]

>> Is the hypervisor adjusting the Virtual Offset Register?
> 
> The virtual offset register is useful when a VCPU is migrated to another
> system to account for the differences in physical time on the two hosts
> but isn't useful for accounting for stolen time while running on a
> single host.
> 
> e.g. if a VCPU sets a timer for NOW+5, but 3 are stolen in the middle it
> would not make sense (from the guests PoV) for NOW'==NOW+2 at the point
> where the timer goes off. Nor does it make sense to require that the
> guest actually be running for 5 before injecting the timer because that
> would mean real time elapsed time for the timer would be 5+3 in the case
> where 3 are stolen.

This is a bit of an aside, but I think that hiding time spent at higher
privilege levels can be a quite sensible approach to timekeeping in a
virtualized environment, but I understand that it's not the approach taken
with Xen, and as you pointed out above, adjusting the Virtual Offset Register
by itself isn't enough to implement that approach.

> So the virtual timer should appear to have been running even while time
> is being stolen and therefore stolen time needs to be accounted via some
> other means.

Something that's not currently obvious to me is that given that the stolen
cycle accounting should be done, what makes the architected timer interrupt
handler the ideal place to do it?

Thanks,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

  reply	other threads:[~2013-05-02 21:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-01 19:27 [PATCH 0/3] xen/arm: account for stolen ticks Stefano Stabellini
2013-05-01 19:27 ` [PATCH 1/3] arm_arch_timer: introduce arch_timer_stolen_ticks Stefano Stabellini
2013-05-01 20:36   ` Christopher Covington
2013-05-02  8:19     ` [Xen-devel] " Ian Campbell
2013-05-02 21:33       ` Christopher Covington [this message]
2013-05-03 10:43         ` Stefano Stabellini
2013-05-03 10:54           ` Marc Zyngier
2013-05-05 16:47             ` Stefano Stabellini
2013-05-06 14:55               ` Christopher Covington
2013-05-06 14:35         ` Konrad Rzeszutek Wilk
2013-05-07 16:17           ` Christopher Covington
2013-05-08 11:19             ` Stefano Stabellini
2013-05-08 11:48               ` Christopher Covington
2013-05-01 19:27 ` [PATCH 2/3] xen: move do_stolen_accounting to drivers/xen/time.c Stefano Stabellini
2013-05-02  8:19   ` [Xen-devel] " Ian Campbell
2013-05-02 18:49   ` Christopher Covington
2013-05-03  8:26     ` [Xen-devel] " Ian Campbell
2013-05-03 10:29       ` Stefano Stabellini
2013-05-01 19:27 ` [PATCH 3/3] xen/arm: account for stolen ticks Stefano Stabellini
2013-05-02  8:21   ` [Xen-devel] " Ian Campbell
2013-05-02 10:38     ` Stefano Stabellini
2013-05-02 10:48       ` Ian Campbell
2013-05-02 10:54         ` Stefano Stabellini
2013-05-02 11:02           ` Ian Campbell
2013-05-02 11:04             ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5182DBA9.9080609@codeaurora.org \
    --to=cov@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).