Sched_ule.c - 8.0

[Murty, Ravi]

Hello All,

 

I was browsing the ULE 8.0 scheduler code and happen to find something
interesting. This might be intentional; since I don't think it is that
big a deal and is certainly not a bug.

In the implementation of sched_affinity - which from what I understand
gets called when the cpuset mask for a thread or a process is setup and
threads need to potentially migrated.

The code is pretty straightforward and one of the checks it does is 

 

if (!TD_IS_RUNNING(td))

    return;

 

I initially read this to mean, if the thread isn't running, it's
probably inhibited and that's okay because when it wanders into
sched_add eventually and since its cpuset mask is setup, it'll make its
way to the runq of one of the "legal" cpus. However the very next
thought I had was this thread could be on a runq right now and the macro
will return the fact that the thread isn't running. In such a case we
would probably end up running on the wrong CPU for a while before
realizing that we aren't allowed to do so.

 

Thanks

Ravi