From: David Ahern <david.ahern@oracle.com>
To: sparclinux@vger.kernel.org
Subject: Re: [PATCH] sparc: perf: Add support M7 processor
Date: Thu, 23 Apr 2015 00:29:12 +0000 [thread overview]
Message-ID: <55383CD8.6050102@oracle.com> (raw)
In-Reply-To: <1426795597-135713-1-git-send-email-david.ahern@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]
On 4/22/15 5:25 PM, David Miller wrote:
> From: David Ahern <david.ahern@oracle.com>
> Date: Wed, 22 Apr 2015 17:19:23 -0600
>
>> Only thing left in my queue is optimized versions of the ffs / fls
>> families, but that patch is v9b specific, not M7.
>
> Something faster than the popc thing in arch/sparc/lib/ffs.S?
hmmm... i saw that, but wasn't clear 1) how it got inserted and 2) the
overhead of a function call versus inline. Anyways, what I have is the
same 3 instructions as an inline. But really the __ffs was just along
for the ride; the focus was on __fls.
>
> Are you thinking of using "lzcnt"? I wasn't impressed with the
> performance of that instruction last time I played around with it.
A comparison of what I hacked together is attached (columns too wide for
inline). Data is from a T4-2. It shows lzcnt to be better for __fls, fls
and fl64.
>
>> I'd like to put some attention on precise mode for perf counters; it
>> just has not bubbled to the top.
>
> That plus the backtrace deadlock thing we're discussing in another
> thread, that bug is irritating because your pagefault_disable() change
> should "just work".
>
oh, yes. forgot about that one. I spent too many hours trying to figure
out why processes get killed with a sigbus. I added an option to perf
tool to skip userspace chains until I can get back to it.
[-- Attachment #2: fls-cmp.txt --]
[-- Type: text/plain, Size: 739 bytes --]
- "slow" means version from asm-generic.
- Times are in nsec.
- 'bit' column shown to ensure correct answer between current and lzcnt
- average of 10 back-to-back calls
| __fls | fls | fls64
word | lzcnt slow | lzcnt slow | lzcnt slow
| bit dt bit dt | bit dt bit dt | bit dt bit dt
0 | 0 15 0 67 | 0 19 0 21 | 0 14 0 14
1 | 0 13 0 50 | 1 32 1 61 | 1 20 1 51
80000000 | 31 13 31 39 | 32 30 32 49 | 64 25 64 37
8000000000000000 | 63 13 63 34 | 0 17 0 16 | 0 12 0 14
next prev parent reply other threads:[~2015-04-23 0:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 20:06 [PATCH] sparc: perf: Add support M7 processor David Ahern
2015-03-20 1:56 ` David Miller
2015-03-20 2:55 ` David Ahern
2015-03-20 19:38 ` David Miller
2015-03-20 19:41 ` David Ahern
2015-03-20 19:50 ` David Miller
2015-04-13 17:53 ` David Ahern
2015-04-16 19:35 ` David Miller
2015-04-21 20:15 ` David Miller
2015-04-22 22:51 ` David Miller
2015-04-22 23:10 ` Khalid Aziz
2015-04-22 23:13 ` David Miller
2015-04-22 23:19 ` David Ahern
2015-04-22 23:25 ` David Miller
2015-04-22 23:30 ` Khalid Aziz
2015-04-23 0:29 ` David Ahern [this message]
2015-04-23 1:39 ` David Miller
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=55383CD8.6050102@oracle.com \
--to=david.ahern@oracle.com \
--cc=sparclinux@vger.kernel.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).