linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).