[PATCH 5/6] arm64: Port SWP/SWPB emulation support from arm

Will Deacon
2014-08-26T13:56:23Z

On Tue, Aug 26, 2014 at 02:26:58PM +0100, Arnd Bergmann wrote:
> On Tuesday 26 August 2014 13:25:43 Will Deacon wrote:
> > On Tue, Aug 26, 2014 at 12:32:23PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 26 August 2014 11:28:49 Punit Agrawal wrote:
> > > >
> > > > This patch ports the alternative solution to emulate the SWP and SWPB
> > > > instructions using LDXR/STXR sequences from the arm port to
> > > > arm64. Additionaly, the patch also proivdes support to log the
> > > > emulation statistics via debugfs.
> > >
> > > I'm not sure that putting this into debugfs is a good idea in this
> > > case: while in general that is considered a good place for this
> > > kind of debugging information, we already have a precedent on arm32
> > > for using procfs, and I see no reason to introduce an incompatible
> > > interface for arm64.
> > >
> > > You also add an interface for disabling the feature at runtime,
> > > which we don't have on arm32, but that interface is not available
> > > if debugfs is disabled or not mounted. Maybe a sysctl would be
> > > more appropriate? That one could also be shared with arm32.
> >
> > One advantage of using debugfs is that it provides a place to keep
> > controls/statistics for any emulations that we add in the future, as opposed
> > to littering them around in /proc or (worse) having a mixture of the two.
>
> Yes, I understood that. I just had another idea: would it make sense to
> use a tracepoint rather than a simple counter? That way you can actually
> see who is using those instructions with ftrace.

That would also be useful for perf, where the plain `emulation fault' event
can be a little too broad.

> You still wouldn't get the files in the same place as the enable switch
> though. The easiest way to implement that switch btw would be a
> module_param: It can be passed on the command line (using
> swp_emulate.enable=0) or at runtime by writing to
> /sys/module/swp_emulate/parameters/enable.
>
> If we do both, there is no longer a need to have any debugfs file logic,
> which is also a plus.

Sounds good to me.

Will