Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1436844
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] perf: fix pmu::filter_match for SW-led groups |
| Date | 2016-07-05 10:40 +0200 |
| Message-ID | <rRu3E-mM-37@gated-at.bofh.it> (permalink) |
| References | <rJYid-6wL-9@gated-at.bofh.it> <rQwhc-5T4-35@gated-at.bofh.it> <rRgtH-sg-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, Jul 04, 2016 at 07:05:35PM +0100, Mark Rutland wrote: > On Sat, Jul 02, 2016 at 06:40:25PM +0200, Peter Zijlstra wrote: > > One of the ways I was looking at getting that done is a virtual runtime > > scheduler (just like cfs). The tricky point is merging two virtual > > runtime trees. But I think that should be doable if we sort the trees on > > lag. > > > > In any case, the relevance to your question is that once we have a tree, > > we can play games with order; that is, if we first order on PMU-id and > > only second on lag, we get whole subtree clusters specific for a PMU. > > Hmm... I'm not sure how that helps in this case. Wouldn't we still need > to walk the sibling list to get the HW PMU-id in the case of a SW group > leader? Since there is a hardware even in the group, it must be part of the hardware pmu list/tree and would thus end up classified (and sorted) by that (hardware) PMU-id. > For the heterogeenous case we'd need a different sort order per-cpu > (well, per microarchitecture), which sounds like we're going to have to > fully sort the events every time they move between CPUs. :/ Confused, I thought that for the HG case you had multiple events, one for each PMU. If we classify these events differently we'd simply use a different subtree depending on which CPU the task lands. Currently we've munged the two PMUs together, because, well, that's the only way. > I also had another though about solving the SW-led group case: if the > leader had a reference to the group's HW PMU (of which there should only > be one), we can filter on that alone, and can also use that in > group_sched_in rather than the ctx->pmu, avoiding the issue that > ctx->pmu is not the same as the group's HW PMU. > > I'll have a play with that approach in the mean time. Right, adds one more pointer to the struct event, but that thing is massive already.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH] perf: fix pmu::filter_match for SW-led groups Peter Zijlstra <peterz@infradead.org> - 2016-07-02 18:50 +0200
Re: [PATCH] perf: fix pmu::filter_match for SW-led groups Mark Rutland <mark.rutland@arm.com> - 2016-07-04 20:10 +0200
Re: [PATCH] perf: fix pmu::filter_match for SW-led groups Peter Zijlstra <peterz@infradead.org> - 2016-07-05 10:40 +0200
Re: [PATCH] perf: fix pmu::filter_match for SW-led groups Mark Rutland <mark.rutland@arm.com> - 2016-07-05 11:50 +0200
Re: [PATCH] perf: fix pmu::filter_match for SW-led groups Peter Zijlstra <peterz@infradead.org> - 2016-07-05 14:10 +0200
Re: [PATCH] perf: fix pmu::filter_match for SW-led groups Mark Rutland <mark.rutland@arm.com> - 2016-07-05 15:00 +0200
csiph-web