Messages in this thread | | | Date | Tue, 27 Oct 2009 03:01:04 +0530 | From | "K.Prasad" <> | Subject | Re: [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events |
| |
On Sat, Oct 24, 2009 at 04:16:52PM +0200, Frederic Weisbecker wrote: > Hi all, > > This is the v2 of the hw-breakpoints API rewrite on top of perf events. > You can find the previous version here: > http://lwn.net/Articles/351922/ > > Changes in v2: > > - Follow the perf "event " rename > - The ptrace regression have been fixed (ptrace breakpoint perf events > weren't released when a task ended) > - Drop the struct hw_breakpoint and store generic fields in > perf_event_attr. > - Separate core and arch specific headers, drop > asm-generic/hw_breakpoint.h and create linux/hw_breakpoint.h > - Use new generic len/type for breakpoint > - Handle off case: when breakpoints api is not supported by an arch > - Use proper in-kernel perf api provided by Arjan. > > There are still a lot of things that need to be cleaned, simplified, > improved (ptrace side, the bp api, etc....) I guess these things can > be done incrementally if you agree. > > I've also tried to get an arch-independent api. Generic fields for > breakpoints are stored in perf_event_attr structure (type, len, addr). > This needs to be discussed and improved before it becomes a perf > userspace ABI. We need to find a generic enough structure to host > the breakpoints parameters, something that can better fit to most arch > (handling breakpoint ranges in powerpc, etc...). >
Outside the specific comments about the implementation here, I think the patchset begets a larger question about hw-breakpoint layer's integration with perf-events.
Upon being a witness to the proposed changes and after some exploration of perf_events' functionality, I'm afraid that hw-breakpoint integration with perf doesn't benefit the former as much as originally wished to be (http://lkml.org/lkml/2009/8/26/149).
Some of the prevalent concerns (which have been raised in different threads earlier) are:
- While kernel-space breakpoints need to reside on every processor (irrespective of the process in user-space), perf-events' notion of a counter is always linked to a process context (although there could be workarounds by making it 'pinned', etc).
- HW Breakpoints register allocation mechanism is 'greedy', which in my opinion is more suitable for allocating a finite and contended resource such as debug register while that of perf-events can give rise to roll-backs (with side-effects such as stray exceptions and race conditions).
- Given that the notion of a per-process context for counters is well-ingrained into the design of perf-events (even system-wide counters are sometimes implemented through individual syscalls over nr_cpus as in builtin-stat.c), it requires huge re-design and user-space changes.
Trying to scoop out the hw-breakpoint layer off its book-keeping/register allocation features only to replace with that of perf-events leads to a poor retrofit. On the other hand, an implementation to enable perf to use hw-breakpoint layer (and its APIs) to profile memory accesses over kernel-space variables (in the context of a process) is very elegant, modular and fits cleanly within the frame-work of the perf-events as a new perf-type (refer http://lkml.org/lkml/2009/10/26/467). A working patchset (under development and containing bugs) is posted for RFC here: http://lkml.org/lkml/2009/10/26/461
It is my opinion that enhancing perf-layer to profile memory accesses through hw-breakpoint layer should be preferred over merging them.
Thanks, K.Prasad
| |