To be used for features we will not support on a particular architecture.
The git log that adds this needs to provide the justification 'why?'
Signed-off-by: Ananth N Mavinakayanahalli <[email protected]>
---
Documentation/features/arch-support.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/features/arch-support.txt b/Documentation/features/arch-support.txt
index d22a109..c0bc92b 100644
--- a/Documentation/features/arch-support.txt
+++ b/Documentation/features/arch-support.txt
@@ -8,4 +8,5 @@ The meaning of entries in the tables is:
| ok | # feature supported by the architecture
|TODO| # feature not yet supported by the architecture
| .. | # feature cannot be supported by the hardware
+ | na | # feature is not needed by the architecture
Kprobes uses a breakpoint instruction to trap into execution flow
and the probed instruction is single-stepped from an alternate location.
On some architectures like x86, under certain conditions, the OPTPROBES
feature enables replacing the probed instruction with a jump instead,
resulting in a significant perfomance boost (both the breakpoint and
single-step exception is bypassed for each kprobe).
Powerpc has an in-kernel instruction emulator. Kprobes on powerpc uses
this emulator already and bypasses the single-step exception, with a
lot less complexity. There is a potential gain to be had with a direct
jump instead of a breakpoint, but the caveats need to be traded off
with the complexity it brings in.
For now, mark OPTPROBES na for powerpc.
Signed-off-by: Ananth N Mavinakayanahalli <[email protected]>
---
.../features/debug/optprobes/arch-support.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/features/debug/optprobes/arch-support.txt b/Documentation/features/debug/optprobes/arch-support.txt
index b8999d8..73662f9 100644
--- a/Documentation/features/debug/optprobes/arch-support.txt
+++ b/Documentation/features/debug/optprobes/arch-support.txt
@@ -27,7 +27,7 @@
| nios2: | TODO |
| openrisc: | TODO |
| parisc: | TODO |
- | powerpc: | TODO |
+ | powerpc: | na |
| s390: | TODO |
| score: | TODO |
| sh: | TODO |
On Mon, Jul 20, 2015 at 04:24:22PM +0530, Ananth N Mavinakayanahalli wrote:
> There is a potential gain to be had with a direct
> jump instead of a breakpoint, but the caveats need to be traded off
> with the complexity it brings in.
>
> For now, mark OPTPROBES na for powerpc.
If we haven't yet investigated whether this feature is something beneficial
to the powerpc kernel, it should just stay as TODO, not be marked as n/a.
Segher
On Mon, 2015-07-20 at 08:41 -0500, Segher Boessenkool wrote:
> On Mon, Jul 20, 2015 at 04:24:22PM +0530, Ananth N Mavinakayanahalli wrote:
> > There is a potential gain to be had with a direct
> > jump instead of a breakpoint, but the caveats need to be traded off
> > with the complexity it brings in.
> >
> > For now, mark OPTPROBES na for powerpc.
>
> If we haven't yet investigated whether this feature is something beneficial
> to the powerpc kernel, it should just stay as TODO, not be marked as n/a.
Yep, agreed. As discussed in the other thread we'll leave this as TODO until we
know it's either not a win or not worth the complexity.
cheers