Hi Dr. Bloom, Is the original test that this patch replaces not good?
I'm afraid so. It only tests if the affinity is respected, but there is no task-shifting in the test. Simulating a WCET is challenging, but you can get an overestimate by > spinning over a running timer until the timeout you want is reached. > There will be error in both the setup and completion, since you won't > know how long it took to read the timer initially and you won't know > how long it took before the timeout was reached and your task yields. Thank you. This sounds good and I'll implement this in a week. I would prefer to add new test cases to smpstrongapa01 and keep the > previous tests if they pass. I am not sure if two CPUs are enough to > fully test this scheduler. Chips with three CPUs are quite unusual, so > why not keep the CPU count at 4? Okay. I'm working to make a basic test with 4 CPUs. It'll be done in a day. On Wed, Sep 2, 2020 at 10:31 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 01/09/2020 20:55, Gedare Bloom wrote: > > Is the original test that this patch replaces not good? Or should you > > provide an additional smpstrongapa02 instead? > > I would prefer to add new test cases to smpstrongapa01 and keep the > previous tests if they pass. I am not sure if two CPUs are enough to > fully test this scheduler. Chips with three CPUs are quite unusual, so > why not keep the CPU count at 4? > > -- > 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. >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel