From: Fortini Matteo <matteo.fortini@mta.it>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Recommended functions for accessing internal registers
Date: Thu, 3 Dec 2009 12:16:05 +0100 [thread overview]
Message-ID: <4B179DF5.90600@mta.it> (raw)
In-Reply-To: <1259787475.2076.1160.camel@pasglop>
I'm on an embedded system, so every resource counts.
One of the biggest impacts is when writing to a communication/memory
access FIFO or reading/writing configurations.
In these cases, I'd just need to make sure that there's no I/O
reordering and/or subsequent r/w are not optimized away, I believe.
Should I switch to the deprecated "volatile" attribute?
Thank you.
Cheers,
Matteo
Il 02/12/2009 21.57, Benjamin Herrenschmidt ha scritto:
> On Tue, 2009-12-01 at 17:44 +0100, Fortini Matteo wrote:
>
>> I see that throughout the kernel source, internal PPC registers are
>> accessed through [in|out]_be[32|16|8]() functions. However, they are
>> translated into 3 inline assembly instructions, one of which is an
>> isync, which has a huge performance hit.
>> I tried using readl_be() which seems to be the right function according
>> to the Documentation/ dir, but it is translated directly to in_be32(),
>> so no luck.
>>
>> Is it really necessary to use all those instructions? I know I could use
>> a (volatile u32 *) variable to avoid subsequent read/writes to be
>> optimized out, but it seems to be a deprecated use.
>>
> There are good reasons why the accessors contain those barriers. What
> are you doing that would be performance critical enough for those to be
> a problem ?
>
> Cheers,
> Ben.
>
>
>
next prev parent reply other threads:[~2009-12-03 11:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 16:44 Recommended functions for accessing internal registers Fortini Matteo
2009-12-02 20:57 ` Benjamin Herrenschmidt
2009-12-03 11:16 ` Fortini Matteo [this message]
2009-12-03 21:10 ` 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=4B179DF5.90600@mta.it \
--to=matteo.fortini@mta.it \
--cc=benh@kernel.crashing.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.