linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] ARM: arch_timers: enable the use of the virtual timer
Date: Mon, 13 Aug 2012 16:30:23 +0100	[thread overview]
Message-ID: <50291D8F.8000103@arm.com> (raw)
In-Reply-To: <50266C23.7040802@ti.com>

On 11/08/12 15:28, Cyril Chemparathy wrote:
> On 8/11/2012 6:31 AM, Marc Zyngier wrote:
>> At the moment, the arch_timer driver only uses the physical timer,
>> which can cause problem if PL2 hasn't enabled PL1 access in CNTHCTL,
>> which is likely in a virtualized environment. Instead, the virtual
>> timer is always available.
>>
>> This patch enables the use of both the virtual timer, unless no
>> interrupt is provided in the DT for it, in which case is falls
>> back to the physical timer.
>>
> 
> I'm curious about the cost of the added pointer chasing introduced by 
> this patch.
> 
> The original code gets nicely inlined by the compiler, and this hides 
> all the switch-case register index stuff.  For instance:
> 
>   10797 c001288c <arch_timer_set_next_event>:
>   10798 c001288c:       ee1e3f32        mrc     15, 0, r3, cr14, cr2, {1}
>   10799 c0012890:       e3c33002        bic     r3, r3, #2
>   10800 c0012894:       ee0e0f12        mcr     15, 0, r0, cr14, cr2, {0}
>   10801 c0012898:       f57ff06f        isb     sy
>   10802 c001289c:       e3833001        orr     r3, r3, #1
>   10803 c00128a0:       ee0e3f32        mcr     15, 0, r3, cr14, cr2, {1}
>   10804 c00128a4:       f57ff06f        isb     sy
>   10805 c00128a8:       e3a00000        mov     r0, #0
>   10806 c00128ac:       e12fff1e        bx      lr
> 
> With the added pointer chasing, we unfortunately lose out on all the 
> work that the compiler used to do for us.  We now end up having to snake 
> our way through the following:

[...]

Yup, that doesn't look too good.

> I think we'd be better off separating between these (virt, phys, ...) 
> implementations at a higher level of operations (set_mode, 
> set_next_event, ...) rather than separating at a register operations 
> level as you have in this patch.

This approach leads to a lot of code duplication, unless we do some ugly
preprocessor hackery (see patch attached). I then get much better code
(smaller, faster), but I'm not sure we want to live with this...

	M.
-- 
Jazz is not dead. It just smells funny...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-arch_timers-enable-the-use-of-the-virtual-timer.patch
Type: text/x-diff
Size: 14514 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120813/b73ddd01/attachment-0001.bin>

  reply	other threads:[~2012-08-13 15:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-11 10:31 [PATCH v2 0/2] arch_timers patches to enable KVM support Marc Zyngier
2012-08-11 10:31 ` [PATCH v2 1/2] ARM: arch_timers: enable the use of the virtual timer Marc Zyngier
2012-08-11 13:37   ` Cyril Chemparathy
2012-08-11 14:28   ` Cyril Chemparathy
2012-08-13 15:30     ` Marc Zyngier [this message]
2012-08-11 10:31 ` [PATCH v2 2/2] ARM: arch_timers: register a time/cycle counter Marc Zyngier

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=50291D8F.8000103@arm.com \
    --to=marc.zyngier@arm.com \
    --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).