Peter Zijlstra [pet...@infradead.org] wrote:
| On Tue, Apr 07, 2015 at 05:34:55PM -0700, Sukadev Bhattiprolu wrote:
| > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
| > index 2b62198..4dc3d70 100644
| > --- a/include/linux/perf_event.h
| > +++ b/include/linux/perf_event.h
| > @@ -240,20 +240,27 @@ struct pmu {
| >      *
| >      * Start the transaction, after this ->add() doesn't need to
| >      * do schedulability tests.
| > +    *
| > +    * Optional.
| >      */
| > -   void (*start_txn)               (struct pmu *pmu); /* optional */
| > +#define PERF_PMU_TXN_ADD  0x1              /* txn to add/schedule event on 
PMU */
| 
| Please do not interleave these flags in the structure. Maybe place it
| near PERF_EVENT_TXN.

Ok.

| 
| > +   void (*start_txn)               (struct pmu *pmu, int flags);
| >     /*
| >      * If ->start_txn() disabled the ->add() schedulability test
| >      * then ->commit_txn() is required to perform one. On success
| >      * the transaction is closed. On error the transaction is kept
| >      * open until ->cancel_txn() is called.
| > +    *
| > +    * Optional.
| >      */
| > -   int  (*commit_txn)              (struct pmu *pmu); /* optional */
| > +   int  (*commit_txn)              (struct pmu *pmu, int flags);
| >     /*
| >      * Will cancel the transaction, assumes ->del() is called
| >      * for each successful ->add() during the transaction.
| > +    *
| > +    * Optional.
| >      */
| > -   void (*cancel_txn)              (struct pmu *pmu); /* optional */
| > +   void (*cancel_txn)              (struct pmu *pmu, int flags);
| >  
| >     /*
| >      * Will return the value for perf_event_mmap_page::index for this event,
| 
| So (again), why also pass the flags to cancel/commit ?
| 
| The transaction state _has_ to already record it, otherwise it doesn't
| know if add/read are part of one.

I had replied to your earlier mail and added a Note to this patch
description. I was hesitating making more intrusive changes to PMUs
that don't care about the new txn type.

But, I agree, it is better to go ahead and update all PMUs to save
the state and check. Will do that in the next version.

Sukadev

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to