testing new SMP scheduler

[Sebastian Huber]

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.

>>   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"?

> 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.

>
>>   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.