From: Scott Wood <scottwood@freescale.com>
To: Kevin Hao <haokexin@gmail.com>
Cc: <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 2/3] powerpc/e6500: hw tablewalk: optimize a bit for tcd lock acquiring codes
Date: Mon, 17 Aug 2015 16:08:14 -0500 [thread overview]
Message-ID: <1439845694.15601.51.camel@freescale.com> (raw)
In-Reply-To: <20150817111655.GA26870@pek-khao-d1.corp.ad.wrs.com>
On Mon, 2015-08-17 at 19:16 +0800, Kevin Hao wrote:
> On Fri, Aug 14, 2015 at 09:44:28PM -0500, Scott Wood wrote:
> > I tried a couple different benchmarks and didn't find a significant
> > difference, relative to the variability of the results running on the
> > same
> > kernel. A patch that claims to "optimize a bit" as its main purpose
> > ought to
> > show some results. :-)
>
> I tried to compare the execution time of these two code sequences with the
> following test module:
>
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/printk.h>
>
> static void test1(void)
> {
> int i;
> unsigned char lock, c;
> unsigned short cpu, s;
>
> for (i = 0; i < 100000; i++) {
> lock = 0;
> cpu = 1;
>
> asm volatile (
> "1: lbarx %0,0,%2\n\
> lhz %1,0(%3)\n\
> cmpdi %0,0\n\
> cmpdi cr1,%1,1\n\
This should be either "cmpdi cr1,%0,1" or crclr, not that it made much
difference. The test seemed to be rather sensitive to additional
instructions inserted at the beginning of the asm statement (especially
isync), so the initial instructions before the loop are probably pairing with
something outside the asm.
That said, it looks like this patch at least doesn't make things worse, and
does convert cmpdi to a more readable crclr, so I guess I'll apply it even
though it doesn't show any measurable benefit when testing entire TLB misses
(much less actual applications).
I suspect the point where I misunderstood the core manual was where it listed
lbarx as having a repeat-rate of 3 cycles. I probably assumed that that was
because of the presync, and thus a subsequent unrelated load could execute
partially in parallel, but it looks like the repeat rate is specifically
talking about how long it is until the execution unit can accept any other
instruction.
-Scott
next prev parent reply other threads:[~2015-08-17 21:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-13 11:51 [PATCH 1/3] powerpc/e6500: remove the stale TCD_LOCK macro Kevin Hao
2015-08-13 11:51 ` [PATCH 2/3] powerpc/e6500: hw tablewalk: optimize a bit for tcd lock acquiring codes Kevin Hao
2015-08-13 18:44 ` Scott Wood
2015-08-14 7:13 ` Kevin Hao
2015-08-15 2:44 ` Scott Wood
2015-08-17 11:16 ` Kevin Hao
2015-08-17 21:08 ` Scott Wood [this message]
2015-08-13 11:51 ` [PATCH 3/3] powerpc/e6500: hw tablewalk: order the memory access when acquire/release tcd lock Kevin Hao
2015-08-14 3:39 ` Scott Wood
2015-08-14 7:13 ` Kevin Hao
2015-08-15 0:44 ` Scott Wood
2015-08-17 11:19 ` Kevin Hao
2015-08-18 7:55 ` [PATCH v2] powerpc/e6500: hw tablewalk: make sure we invalidate and write to the same tlb entry Kevin Hao
2015-10-17 0:01 ` [v2] " Scott Wood
2015-10-22 12:19 ` Kevin Hao
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=1439845694.15601.51.camel@freescale.com \
--to=scottwood@freescale.com \
--cc=haokexin@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.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).