On Thu, 2012-08-16 at 21:17 +1000, Michael Neuling wrote:
Peter,
=20
quoted
quoted
On this second syscall, fetch_bp_busy_slots() sets slots.pinned to be=
1,
quoted
quoted
despite there being no breakpoint on this CPU. This is because the c=
all
quoted
quoted
the task_bp_pinned, checks all CPUs, rather than just the current CPU=
.
quoted
quoted
POWER7 only has one hardware breakpoint per CPU (ie. HBP_NUM=3D1), so=
we
quoted
quoted
return ENOSPC.
=20
I think this comes from the ptrace legacy, we register a breakpoint on
all cpus because when we migrate a task it cannot fail to migrate the
breakpoint.
=20
Its one of the things I hate most about the hwbp stuff as it relates to
perf.
=20
Frederic knows more...
=20
Maybe I should wait for Frederic to respond but I'm not sure I
understand what you're saying.
=20
I can see how using ptrace hw breakpoints and perf hw breakpoints at the
same time could be a problem, but I'm not sure how this would stop it.
ptrace uses perf for hwbp support so we're stuck with all kinds of
stupid ptrace constraints.. or somesuch.
Are you saying that we need to keep at least 1 slot free at all times,
so that we can use it for ptrace?
No, I'm saying perf-hwbp is weird because of ptrace, maybe the ptrace
weirdness shouldn't live in perf-hwpb but in the ptrace-perf glue
however..
Is "perf record -e mem:0x10000000 true" ever going to be able to work on
POWER7 with only one hw breakpoint resource per CPU? =20
I think it should work... but I'm fairly sure it currently doesn't
because of how things are done. 'perf record -ie mem:0x100... true'
might just work.
I always forget all the ptrace details but I am forever annoyed at the
mess that is perf-hwbp.. Frederic is there really nothing we can do
about this?
The fact that ptrace hwbp semantics are different per architecture
doesn't help of course.