Messages in this thread | | | Date | Fri, 15 Nov 2013 13:33:37 +0100 | From | Peter Zijlstra <> | Subject | Re: perf code using smp_processor_id() in preemptible [00000000] code |
| |
On Fri, Nov 15, 2013 at 04:10:51PM +0400, Cyrill Gorcunov wrote: > On Fri, Nov 15, 2013 at 12:51:50PM +0100, Peter Zijlstra wrote: > > ok, this will make the error go away, but what about the semantics of > > the case? Does it really matter for the grouping on which cpu we compute > > it? That is can we end up with a different group for one cpu as for > > another? > > > > Or do we simply need a coherent single cpu to do the computation with? > > In which case raw_smp_processor_id() would also suffice. > > > > If we can indeed get a different result depending on which cpu we do the > > computation, then things are broken, because it might be a task group > > we're building which has to be able to migrate around with the task. > > The events are sensitive to which cpu they're scheduled to execute on > (if HT is turned on, we need to setup thread bit in register). > As far as I understand once events are assigned to cpu_hw_events > they are executing on this cpu, when tasks are migrated to another > cpu, they're re-scheduled. Or I miss something obvious here?
No this is correct, but that is simply about event encoding, right?
The situation we should be avoiding is:
{x, y, z}
being a valid event group on ht0 but an invalid group for ht1.
So the whole fake_cpuc / validate_{event,group} code that triggered this isn't actually scheduling them, its testing to see if all the provided events could possibly be scheduled together -- and we would want to avoid giving a sibling dependent answer here.
| |