Re: [PATCH 5/7] hw-breakpoints: Rewrite the hw-breakpoints layeron top of perf events

[Frederic Weisbecker]

On Mon, Nov 16, 2009 at 07:58:11PM +0530, K.Prasad wrote:
> On Thu, Nov 12, 2009 at 04:19:52PM +0100, Frederic Weisbecker wrote:
> > On Sun, Nov 08, 2009 at 11:01:07PM +0530, K.Prasad wrote:
> > > 
> > > A few more observations....
> > > 
> > > int reserve_bp_slot(struct perf_event *bp)
> > > {
> > > ...
> > > ....
> > > 	if (!bp->attr.pinned) {
> > > 		/*
> > > 		 * If there are already flexible counters here,
> > > 		 * there is at least one slot reserved for all
> > > 		 * of them. Just join the party.
> > > 		 *
> > > 		 * Otherwise, check there is at least one free slot
> > > 		 */
> > > 		if (!slots.flexible && slots.pinned == HBP_NUM) {
> > > 			ret = -ENOSPC;
> > > 			goto end;
> > > 		}
> > > 
> > > 	/* Flexible counters need to keep at least one slot */
> > > 	} else if (slots.pinned + (!!slots.flexible) == HBP_NUM) {
> > > 		ret = -ENOSPC;
> > > 		goto end;
> > > 	}
> > > ..
> > > ...
> > > }
> > > 
> > > It appears that you're reserving one slot for the non-pinned breakpoint
> > > requests, which I'm afraid wouldn't play well with PPC64 (having one
> > > DABR).
> > 
> > I don't understand what you mean. PPC64 has only one DABR, or...?
> > 
> 
> Yes, PPC64 has just one DABR. And so this scheme will allow the first
> request (be it 'pinned' or 'unpinned') to use the debug register? Sounds
> fine.
> 


After what you, Paul and Benjamin told me, I now doubt about the possibility
of a generic core set of constraints. May be all that should move into x86 code
because it will be hard to find robust and flexible enough generic constraints.

Anyway, we'll see how that evolves.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/