Hi, all

quoted text
>From the discussion of thread "[RFC] perf_events: support for uncore
a.k.a. nest units", in order to support multiple hw pmu, Peter suggested
the first thing that needs to be done is get rid of all the __weak
functions (with exception of perf_callchain*, since that really is arch
specific), includes

hw_perf_group_sched_in
hw_perf_event_init
hw_perf_disable
hw_perf_enable

Peter Zijlstra <peterz@infradead.org> wrote:
quoted text
> One thing not on that list, which should happen first I guess, is to
> remove hw_perf_group_sched_in(). The idea is to add some sort of
> transactional API to the struct pmu, so that we can delay the
> schedulability check until commit time (and roll back when it fails).
>
> Something as simple as:
>
>  struct pmu {
>    void start_txn(struct pmu *);
>    void commit_txn(struct pmu *);
>
>    ,,,
>  };
>
> and then change group_sched_in() to use this instead of
> hw_perf_group_sched_in(), whose implementations mostly replicate
> group_sched_in() in various buggy ways anyway.
>

This patch series is to remove hw_perf_group_sched_in() first.

patch 1: core, add group scheduling transactional APIs
patch 2: x86, implement group scheduling transactional APIs
patch 3: powerpc, implement group scheduling transactional APIs
patch 4: sparc, implement group scheduling transactional APIs

I have tested these patches on x86, but for powerpc and sparc it's only
cross build tested.
It's very appreciated if anybody has powerpc or sparc can help to test. 

Thanks for any comment.

Changes log:

v2.
Change transaction flag(cpu_hw_events->group_flag) from u8 to unsigned
int. RISC architecture deals better with word sized variable than u8.
(Peter Zijlstra)

Rename callback names, *_txn -> *_group_trans for better readability.
Add a few comments to describe the callbacks. (Frederic Weisbecker)

v1.
remove __weak function hw_perf_group_sched_in() based on Peter's idea.

Thanks,
Lin Ming

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