testing new SMP scheduler

[Chris Johns]

Sebastian Huber 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:
>>> 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 agree. This is needed.

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

I would go a step further and remove the call. We should flag this when 
building and returning a suitable error code for a release then remove 
it for the next release. Users can change their code to set the priority 
of the executing task to highest possible value for the exclusion 
period. Their code would make more sense when being reviewed and there 
is no implied notion of locking.

This change means we need a classic condition variable API to fix the 
bdbuf code.

>
> What is the use case for "stay on the core"?
>

The only case should be defined by making the task the highest priority. :)

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

It is needed to implement timeslicing for tasks with the same priority 
in a fair way. Consider 5 tasks with the same priority and timeslicing 
enabled on a 2 core system.

Chris