Patch for pthread get and set affinity

[Joel Sherrill]

On 3/6/2014 1:38 AM, Sebastian Huber wrote:
> On 2014-03-05 17:31, Gedare Bloom wrote:
>> Joel,
>>
>> On Wed, Mar 5, 2014 at 10:38 AM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> On 3/5/2014 9:05 AM, Sebastian Huber wrote:
>>>> On 2014-03-05 15:58, Joel Sherrill wrote:
>>>>> On Mar 5, 2014 8:33 AM, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>>>>   >
>>>>>   > On 2014-03-05 15:21, Joel Sherrill wrote:
>>>>>   > > We discussed this privately when you raised this to me. It should not be part
>>>>>   > > of the scheduler per thread data. lf you do then the data just disappears from
>>>>>   > > the API perspective when the scheduler doesn't support affinity. It will
>>>>> create
>>>>>   > > a new class of odd errors at the API level which no other implementation of
>>>>>   > > this type of API has. From an API perspective, it is the same as the preempt
>>>>>   > > and timeslicing flags.
>>>>>   >
>> Oops I forgot about our chat. I do think we need to revisit the issue
>> in the future though, and probably add calls to the scheduler from the
>> score affinity implementation.
>>
>>>>>   > It is the responsibility of the scheduler set/get thread affinity operation to
>>>>>   > validate/return the affinity sets.  Storing this stuff in an arbitrary format
>>>>>   > in the Thread_Control structure makes no sense since the thread affinity
>>>>>   > support is entirely scheduler dependent.
>>>>>   >
>>>>>   > >
>>>>>   > > It is disabled in non-smp configurations, so doesn't impact minimum footprint.
>>>>>   > >
>>>>>   > > I seriously considered this and decided it was a bad idea. I don't know if I
>>>>>   > > have veto power :) but if I did, I would invoke it here.
>>>>>   > >
>>>>>   > > We can revisit this when we have a scheduler with affinity. As it stands now,
>>>>>   > > there is absolutely no way to test any of this code if we move the affinity
>>>>>   > > data to the scheduler.
>>>>>   > >
>>>>>   >
>>>>>   > You can test the code if you add the scheduler set/get affinity operations.
>>>>>   > The default implementation is trivial.  We have only global schedulers, so
>>>>>   > simply check that the affinity set is the set of all processors in the system.
>>>>>   >   For the get simply return the set of all processors.
>>>>>
>>>>> I don't disagree with this statement but you are being short sighted for
>>>>> iterative development.
>>>>>
>>>>> If we do this, then the tests can't set an arbitrary affinity and return it.
>>>>> We can commit this set will full passing tests.
>>>>>
>>>>> We will move the set when we touch the schedulers. We were very open and public
>>>>> and getting the APIs in and tested with data consistency and no scheduler
>>>>> changes as step one. Step two moves the information into the schedulers.
>>>>>
>>>>> If we make this change, we will commit nearly all broken tests
>>>>>
>>>> Its fine if you move the information into the schedulers later.  This wasn't
>>>> obvious from the current patch set.
>>>>
>>> Great! Thanks. I just started hacking on the scheduler part and it would
>>> be better to commit what we have and make sure it works before doing
>>> more.
>>>
>>> Unless someone has someone has something else, Jennifer is going
>>> to commit and verify that the resulting master matches her results.
>>>
>> OK with me. I would like you to add a note to the SMP wiki page
>> regarding this issue about affinity in the TCB vs the scheduler. It
>> seems to me that any SMP scheduler must deal with the affinity API
>> whether or not the scheduler supports thread affinity---the scheduler
>> can return an error if an application tries to use affinity calls but
>> the scheduler does not support affinity.
> All thread affinity support must move to the scheduler in the long run (data 
> and operations).  I see no way to implement this scheduler agnostic.
>
We agree and are in the process of addressing this. We will initially
just add
the plugin points to the scheduler framework, get/set with all CPUs for the
existing SMP schedulers,  and add a variant which at least stores the cpuset
so the affinity tests can be data consistent.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985