From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT
Date: Wed, 27 Jul 2016 11:33:42 +0800 [thread overview]
Message-ID: <20160727113342.2a839c1a@xhacker> (raw)
In-Reply-To: <57976FA5.2070802@codeaurora.org>
+1
On Tue, 26 Jul 2016 09:11:49 -0500 Timur Tabi wrote:
> Will Deacon wrote:
> > The kernel really needs to support both of those platforms :/
> >
> > For the memory-mapped counter registers, the architecture says:
> >
> > `If the implementation supports 64-bit atomic accesses, then the
> > CNTV_CVAL register must be accessible as an atomic 64-bit value.'
> >
> > which is borderline tautological. If we take the generous reading that
> > this means AArch64 CPUs can use readq (and I'm not completely
> > comfortable with that assertion, particularly as you say that it breaks
> > the model), then you still need to use readq_relaxed here to avoid a
> > DSB. Furthermore, what are you going to do for AArch32? readq doesn't
> > exist over there, and if you use the generic implementation then it's
> > not atomic. In which case, we end up with the current code, as well as a
> > readq_relaxed guarded by a questionable #ifdef that is known to break a
> > supported platform for an unknown performance improvement. Hardly a big
> > win.
>
> I know Fu dropped this patch, and I don't want to kick a dead horse, but
> I was wondering if it would be okay to do this:
>
> static u64 arch_counter_get_cntvct_mem(void)
> {
> #ifdef readq_relaxed
> return readq_relaxed(arch_counter_base + CNTVCT_LO);
> #else
> u32 vct_lo, vct_hi, tmp_hi;
>
> do {
> vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
> vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
> tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
> } while (vct_hi != tmp_hi);
>
> return ((u64) vct_hi << 32) | vct_lo;
> #endif
> }
>
> readq and readq_relaxed are defined in arch/arm64/include/asm/io.h. Why
> would the function exist if AArch64 CPUs can't use it?
+1
I measured the performance on berlin arm64 platforms:
compared with original version, using readq_relaxed could reduce
time of arch_counter_get_cntvct_mem() by about 42%!
Thanks,
Jisheng
next prev parent reply other threads:[~2016-07-27 3:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-25 15:26 [PATCH v9 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer fu.wei at linaro.org
2016-07-25 15:26 ` [PATCH v9 1/9] clocksource/drivers/arm_arch_timer: Move enums and defines to header file fu.wei at linaro.org
2016-07-25 15:27 ` [PATCH v9 2/9] clocksource/drivers/arm_arch_timer: Add a new enum for spi type fu.wei at linaro.org
2016-07-25 15:27 ` [PATCH v9 3/9] clocksource/drivers/arm_arch_timer: Improve printk relevant code fu.wei at linaro.org
2016-07-25 15:27 ` [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT fu.wei at linaro.org
2016-07-25 15:31 ` Will Deacon
2016-07-25 15:50 ` Timur Tabi
2016-07-25 15:55 ` Fu Wei
2016-07-25 16:31 ` Will Deacon
2016-07-25 22:49 ` Russell King - ARM Linux
2016-07-26 9:21 ` Fu Wei
2016-07-26 14:11 ` Timur Tabi
2016-07-27 3:33 ` Jisheng Zhang [this message]
2016-07-27 4:19 ` Fu Wei
2016-07-28 13:53 ` Will Deacon
2016-07-25 15:27 ` [PATCH v9 5/9] acpi/arm64: Add GTDT table parse driver fu.wei at linaro.org
2016-07-26 11:50 ` Rafael J. Wysocki
2016-07-26 12:40 ` Fu Wei
2016-07-25 15:27 ` [PATCH v9 6/9] clocksource/drivers/arm_arch_timer: Simplify ACPI support code fu.wei at linaro.org
2016-07-25 15:27 ` [PATCH v9 7/9] acpi/arm64: Add memory-mapped timer support in GTDT driver fu.wei at linaro.org
2016-07-25 15:27 ` [PATCH v9 8/9] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer fu.wei at linaro.org
2016-07-25 15:27 ` [PATCH v9 9/9] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver fu.wei at linaro.org
2016-08-09 11:03 ` [PATCH v9 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer Tomasz Nowicki
2016-08-09 18:12 ` Fu Wei
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=20160727113342.2a839c1a@xhacker \
--to=jszhang@marvell.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).