From: Becky Bruce <becky.bruce@freescale.com>
To: linuxppc64-dev@ozlabs.org, linuxppc-embedded@ozlabs.org,
linuxppc-dev@ozlabs.org
Subject: cpu features testing 32 vs 64 bit
Date: Thu, 8 Sep 2005 16:02:31 -0500 [thread overview]
Message-ID: <1729b6f2a199a759c4daeadd3ddcdc4a@freescale.com> (raw)
So,
in include/asm-ppc64/cacheflush.h is the following:
static inline void flush_icache_range(unsigned long start, unsigned
long stop)
{
if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
__flush_icache_range(start, stop);
}
On the 32-bit side, we don't need the feature test -
CPU_FTR_COHERENT_CACHE is only defined in 64-bit land, and has bits set
in the upper 32.
There's a couple of ways to deal with merging this:
1) The ever-so-popular #ifdef __powerpc64__around the cpu_has_feature
test
2) No ifdef in the code itself, but #define CPU_FTR_WHATEVER to be 0
when !__powerpc64__ in cputable.h so that the cpu_has_feature test will
always fail for 32-bit.
I'd like to get some opinions on this. Do folks feel like the
performance hit of doing the compare is enough to justify going with
method 1? Should we be using likely/unlikely with the feature test?
This is just one code example - I suspect there will be others as we
continue the merge, and the importance of performance may differ
depending on where in the code we are.
Thanks!
-B
next reply other threads:[~2005-09-08 21:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-08 21:02 Becky Bruce [this message]
2005-09-08 21:08 ` cpu features testing 32 vs 64 bit Pantelis Antoniou
2005-09-08 21:20 ` Kumar Gala
2005-09-08 21:48 ` Dan Malek
2005-09-08 22:02 ` Kumar Gala
2005-09-08 22:20 ` Dan Malek
2005-09-08 22:36 ` Arnd Bergmann
2005-09-09 0:08 ` David Gibson
2005-09-09 4:23 ` [PATCH] powerpc: merge include/asm/cputable.h Arnd Bergmann
2005-09-14 19:11 ` Kumar Gala
2005-09-14 23:58 ` Arnd Bergmann
2005-09-15 17:44 ` Kumar Gala
2005-09-15 22:56 ` Arnd Bergmann
2005-09-16 2:22 ` Kumar Gala
2005-09-16 3:11 ` Arnd Bergmann
2005-09-16 21:40 ` Kumar Gala
2005-09-17 0:36 ` Arnd Bergmann
2005-09-09 22:19 ` cpu features testing 32 vs 64 bit Benjamin Herrenschmidt
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=1729b6f2a199a759c4daeadd3ddcdc4a@freescale.com \
--to=becky.bruce@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=linuxppc64-dev@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).