Scheduler Set Affinity Design Thoughts

[Sebastian Huber]

Hello Joel,

please have a look at the attached patch.

On 2014-05-20 23:24, Joel Sherrill wrote:
> On 5/19/2014 1:34 AM, Sebastian Huber wrote:
>> >On 2014-05-16 19:48, Joel Sherrill wrote:
>>> >>Hi
>>> >>
>>> >>Questions first:
>>> >>
>>> >>+ The affinity mask must be non-empty. This means a thread must
>>> >>be able to be scheduled on some processor.  With cluster scheduling,
>>> >>a scheduler implementation would only be associated with a subset
>>> >>of processors. The affinity can't be set such that the thread can't be
>>> >>scheduled by this scheduler instance.
>> >Ok.
>> >
>>> >>How can a scheduler instance
>>> >>know which processors it is associated with?
>> >You can store this information in the scheduler context if it needs this
>> >information quickly or you have iterate though the scheduler assignments:
> I started to implement some validation but then looked back at
> _Scheduler_Set_affinity() and it only invokes the scheduler specific
> set affinity if it is in the cpu set. So it is checked out before you
> get to the operation.
>
> But, I think blindly invoking the first scheduler instance that
> the thread has affinity for is dangerous and incorrect.

Since we don't allow a CPU set to overlap two or more scheduler instances, this 
is correct with the current default operation.  In the patch I moved some 
checks from the default operation to _Scheduler_Set_affinity() to make it more 
clear.

>
> I do not think that _Scheduler_Set_affinity() properly
> addresses the case where the old affinity set is on one scheduler
> instance and the new set moves it to another. The source scheduler
> doesn't appear to get a chance to remove it from its bookkeeping.

The _Scheduler_default_Set_affinity() calls _Scheduler_Set() after it validated 
the CPU set.  The _Scheduler_Set() does all the bookkeeping.  You probably have 
to split the _Scheduler_Set() sequence up to also account for the CPU set.

>
> It is pretty clear that _Scheduler_Set_affinity() doesn't address this
> because it blindly invokes the first scheduler instance the new
> affinity matches without concern over whether that was the previous
> schedule instance.
>
> The scheduler specific affinity routine can't address this because it
> won't see it leaving.
>
> I repeat that I really don't think changing affinity should move a
> thread from one scheduler instance to another.  It is non-obvious
> behavior and has some subtle side-effects that need to be managed.
> _Scheduler_Set_affinity() could enforce this.

The pthread_setaffinity_np() is the only way to set the scheduler via the 
non-portable POSIX API.  So I would keep the ability to change the scheduler 
with it.

>
> Moving schedulers and changing affinity should be rare and very
> explicit operations.


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-score-_Scheduler_Set_affinity.patch
Type: text/x-patch
Size: 4898 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140521/66fd28b1/attachment-0001.bin>