On Fri, Jun 14, 2013 at 12:29 PM, Sebastian Huber <sebastian.hu...@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.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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
