[PATCH] [ARM] Introduce patching of phys_to_virt and vice versa
nico at fluxnic.net
Tue Sep 28 13:51:37 EDT 2010
On Tue, 28 Sep 2010, Eric Miao wrote:
> On Tue, Aug 10, 2010 at 12:55 AM, Nicolas Pitre <nico at fluxnic.net> wrote:
> > On Sun, 8 Aug 2010, Russell King - ARM Linux wrote:
> >> On Fri, Aug 06, 2010 at 01:07:46PM -0400, Nicolas Pitre wrote:
> >> > No idea. That depends how gcc is considering inline asm. Given there
> >> > is one input operand, I suppose gcc would account for the delay slot
> >> > before that operand is actually available.
> >> For something which could very well become by default enabled across
> >> the board - due to the push to have a single kernel binary for lots
> >> of significantly different platforms - it seems little research has
> >> been carried out on this point.
> >> While I agree that other obvious solutions would be more expensive, I
> >> think it makes sense to have the commit which is introducing this
> >> method include a proper evaluation, not least so that people who need
> >> to make the decision to enable this aren't repeating the same research
> >> that someone else has done (or, worse, just decide to enable it 'just
> >> because' without any understanding of what the effect may be.)
> > Sure, I agree. I'll contact gcc people for a definitive answer.
> Nico, any feedback?
Yes. As far as scheduling goes, the current gcc implementation simply
considers any inline assembly as a pipeline flush. This is not perfect,
but without the volatile this is still acceptable as demonstrated by
your comparison example, probably better than dereferencing a global
variable. I'll ask the Linaro toolchain group to see if it is
possible to improve gcc for this, but I suspect the improvement would be
marginal compared to the current results.
> >> I think we also need to consider whether the volatile is really required.
> >> This asm() doesn't have any side effects other than its output operand,
> >> so I suspect that the volatile may get in the way of some optimisations
> >> (such as deleting the operation if the output is not actually used.)
> > Indeed, the volatile should go. This is even getting in the way of
> > better scheduling.
> Yep. I don't see the necessity here for the volatile. Actually after removing
> it, it resulted a better instruction scheduling.
Indeed. The volatile qualifier for inline assembly is a big hammer
preventing any code movement around and across them.
More information about the linux-arm-kernel