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
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
