lkml.org 
[lkml]   [2013]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.


\
 
 \ /
  Last update: 2013-11-15 14:21    [W:6.406 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site