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>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.