testing new SMP scheduler

[Gedare Bloom]

On Fri, Jun 14, 2013 at 12:29 PM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 14/06/13 17:16, Joel Sherrill wrote:
>>
>> On 6/14/2013 6:03 AM, Sebastian Huber wrote:
>>>
>>> On 06/13/2013 11:30 PM, Joel Sherrill wrote:
>>>>
>>>> Hi
>>>>
>>>> Out of curiosity, did you hack confdefs.h to force this as the
>>>> scheduler in uniprocessor configurations to ensure it does
>>>> the correct things in that situation?
>>>>
>>> I hacked some things to run the tests with the new scheduler.
>>
>> Unfortunately, I think this is an important thing to test but not
>> necessarily
>> what you want for systems.
>
>
> Yes, its an important test.  I had to revert the task delete -> suspend
> patch.
>
Would it be good to generalize the "hacks" so the sptests can use smp
schedulers?

>
>>>   I added also the
>>> support for the preempt mode (this makes no sense on SMP).
>>
>> Preemption (and timeslicing) still make sense.  When a task is no preempt,
>> it
>> should stay on the core until it voluntarily blocks or makes itself
>> preemptible.
>> This effectively means the scheduler has to avoid kicking it off while no
>> preempt.
>>
>
> Yes, timeslicing makes sense.
>
> I would drop the preempt mode on SMP and return an error status if someone
> wants to use it.  Its to dangerous.  In uni-processor systems the preempt
> mode can be used to enforce mutual exclusion (a broken concept from my point
> of view), but this is no longer true on SMP.  The preempt mode also
> circumvents the priority mechanism.
>
> What is the use case for "stay on the core"?
>
I agree, and I do not know when non-preemption makes sense for SMP.

>
>> Does the scheduler take into account "time on CPU" when considering
>> tasks of equal priority? It should evict the one which has been executing
>> the longest.
>
>
> No, the execution time is completely irrelevant for a priority based
> scheduler.
>
+1

>
>>
>>>   The following tests
>>> fail:
>>>
>>> sp02 - This is a bug in the test.  I will send a fix.
>
>
> I will have to take a closer look into this.
>
>
>>> sp66 - I think there is a bug in the test.
>>> spfatal03 - Fails due to RTEMS_SMP is defined.
>>> tm20 - Didn't look at it since this test tinkers with internal variables.
>>> tm27 - Ditto.
>>>
>>> The test sp66 checks the priority ceiling protocol.  The problem is that
>>> the
>>> driver task has preemption disabled:
>>>
>>> [...]
>>>     sleep(1);
>>>
>>>     puts( "Calling semaphore release" );
>>>     status = rtems_semaphore_release( Mutex_id );
>>>     directive_failed( status, "rtems_semaphore_release" );
>>>
>>> To make sure the priority ceiling works, we have to check that Task_1
>>> actually
>>> runs which is impossible since Init has preempt disabled.
>>>
>>>     puts( "*** END OF TEST 65 ***" );
>>>
>>>     rtems_test_exit(0);
>>> [...]
>>>
>> Does sp66 run with the uniprocessor schedulers?
>>
>
> Yes, but I think the test is incomplete.  We should check that right before
> the end the other task has a higher priority.
>
>
> --
> 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.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel