On 2014-05-12 19:37, Jennifer Averett wrote:
Attached is a scheduler simulator scenario, expected, and output files from one
of
the tests for the smp simple scheduler. It appears that tasks of
the same priority running on different cores are no longer selected for
preemption in fifo order. The executing list is FIFO per priority and the
search is from the rear so the newest at a priority is selected, not
the oldest.
Yes, this conforms to the requirements of the G-FP (global fixed priority)
scheduler. The highest priority (lowest priority number) threads get a
processor assigned. So in your scenario we start with four idle threads (id.prio):
i4.255 <= i3.255 <= i2.255 <= i1.255
Start tasks t1, t2, t3, t4 and t5.
t1.3 < t5.5 < t2.6 < t3.7 < t4.8 < i4.255 <= i3.255 <= i2.255 <= i1.255
Start tasks t6 and t7. Please note that t6 has a lower priority than t5 (see
also _Scheduler_priority_Enqueue()). For example on a uni-processor system if
you execute with priority X and start a task with priority X, then there will
be no pre-emption.
t1.3 < t5.5 <= t6.5 <= t7.5 < t2.6 < t3.7 < t4.8 < i4.255 <= i3.255 <= i2.255
<= i1.255
Start task t8.
t1.3 < t8.4 < t5.5 <= t6.5 <= t7.5 < t2.6 < t3.7 < t4.8 < i4.255 <= i3.255 <=
i2.255 <= i1.255
This is why t8.4 uses the processor previously assigned to t7.5.
This was confirmed on the simple SMP priority but should also be on
the regular SMP priority. I just haven't confirmed it yet.
This is the type of thing the scheduler simulator is very good at helping
to root out. I don't know if a test exists to verify this behaviour. But it
changed
from the original implementation.
Jennifer Averett
On-Line Applications Research
--
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.hu...@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@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
