Scheduler Set Affinity Design Thoughts
sebastian.huber at embedded-brains.de
Wed May 21 08:19:29 UTC 2014
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:
>>> >>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.
>>> >>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
> 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
> 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...
Size: 4898 bytes
Desc: not available
More information about the devel