Messages in this thread | | | Date | Wed, 20 May 2015 18:28:11 +0200 | From | Peter Zijlstra <> | Subject | Re: perf: odd event scheduling issue |
| |
On Wed, May 20, 2015 at 06:08:02PM +0200, Peter Zijlstra wrote: > @@ -2062,6 +2081,22 @@ intel_get_excl_constraints(struct cpu_hw_events *cpuc, struct perf_event *event, > */ > > /* > + * Do not allow scheduling of more than max_alloc_cntrs > + * which is set to half the available generic counters. > + * > + * This helps avoid counter starvation of sibling thread > + * by ensuring at most half the counters cannot be in > + * exclusive mode. There is not designated counters for the > + * limits. Any N/2 counters can be used. This helps with > + * events with specifix counter constraints > + */ > + if (xl->num_alloc_cntrs++ >= xl->max_alloc_cntrs) { > + /* wipe the GP counters */ > + cx->idxmsk64 &= ~((1ULL << INTEL_PMC_IDX_FIXED) - 1); > + goto done; > + } > + > + /* > * Modify static constraint with current dynamic > * state of thread > *
While this improves things, its still sub optimal because we should only increase num_alloc_cntrs when we actually allocate a GP register, but we do that at commit time and that callback is too late to back out / retry.
So ideally we'd move the callback into scheduling code, but that means we also have to move the xlo array into the sched_state etc.
[ which brings me to the whole xl vs xlo thing, I think we done that the wrong way around. It would be more natural to account to xl and create constraints based on xlo. ]
Secondly, we should only enforce this limit if and when there are exclusive events on the system I suppose.
I have some ideas on how to go do this, but I need a break..
| |