lkml.org 
[lkml]   [2009]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5/7] hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf events
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.



\
 
 \ /
  Last update: 2009-11-17 02:43    [W:0.080 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site