Introducing the Strong APA Scheduler

Sat Sep 12 14:14:56 UTC 2020

This makes sense. Thanks for the explanation.

On Fri, Sep 11, 2020 at 3:27 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Thu, Sep 10, 2020 at 12:56 PM Richi Dubey <richidubey at gmail.com> wrote:
> >
> > Yes.
> >
> >> You'll want to run a "clean" version also for comparison, to isolate
> >> problems you might introduce.
> >
> > Shouldn't the clean version give no errors and timeouts? Cause mine does
> give failures.
> >
>
> There are sometimes bugs or things we know that are broken. So you
> need to know the baseline state.
>
> > On Thu, Sep 10, 2020 at 9:02 PM Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> On Mon, Sep 7, 2020 at 8:55 AM Richi Dubey <richidubey at gmail.com>
> wrote:
> >> >
> >> > Invalid directory. Sorry for the doubt.
> >> >
> >>
> >> Did you get it working?
> >>
> >> You'll want to run a "clean" version also for comparison, to isolate
> >> problems you might introduce.
> >>
> >> > On Mon, Sep 7, 2020 at 8:18 PM Richi Dubey <richidubey at gmail.com>
> wrote:
> >> >>>
> >> >>> You should run all tests that doesn't explicitly configure a
> scheduler
> >> >>> with your new implementation.
> >> >>
> >> >> I understand.
> >> >>
> >> >>>
> >> >>> Maybey add an
> >> >>> #ifndef CONFIGURE_MAXIMUM_PROCESSORS
> >> >>> #define CONFIGURE_MAXIMUM_PROCESSORS 1
> >> >>> #endif
> >> >>> before the default scheduler selection.
> >> >>
> >> >> This works.
> >> >>
> >> >> I am getting this error:
> >> >> ./rtems-test \ --log=log_leon3_sis \ --rtems-bsp=leon3-sis \
> ~/quick-start/build/b-smp-leon3/sparc-rtems5/c/leon3/testsuites
> >> >> error: RTEMS Toolkit python wrapper not found, please report
> >> >>
> >> >> As far as I remember, I had done --enable-tests while building my
> bsp.
> >> >>
> >> >> On Mon, Sep 7, 2020 at 7:45 PM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
> >> >>>
> >> >>> On 07/09/2020 16:09, Richi Dubey wrote:
> >> >>>
> >> >>> >     Did you
> >> >>> >     use rtems-test before?
> >> >>> >
> >> >>> > No. I'll do it now.
> >> >>> >
> >> >>> > I am individually testing each smp test for now on this patch:
> >> >>> You should run all tests that doesn't explicitly configure a
> scheduler
> >> >>> with your new implementation.
> >> >>> > ---
> >> >>> >  cpukit/include/rtems/confdefs/scheduler.h | 2 +-
> >> >>> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>> >
> >> >>> > diff --git a/cpukit/include/rtems/confdefs/scheduler.h
> >> >>> > b/cpukit/include/rtems/confdefs/scheduler.h
> >> >>> > index 9305fc2d90..a93e765e53 100644
> >> >>> > --- a/cpukit/include/rtems/confdefs/scheduler.h
> >> >>> > +++ b/cpukit/include/rtems/confdefs/scheduler.h
> >> >>> > @@ -55,7 +55,7 @@
> >> >>> >    && !defined(CONFIGURE_SCHEDULER_STRONG_APA) \
> >> >>> >    && !defined(CONFIGURE_SCHEDULER_USER)
> >> >>> >    #if defined(RTEMS_SMP) && _CONFIGURE_MAXIMUM_PROCESSORS > 1
> >> >>> > -    #define CONFIGURE_SCHEDULER_EDF_SMP
> >> >>> > +    #define CONFIGURE_SCHEDULER_STRONG_APA
> >> >>> >    #else
> >> >>> >      #define CONFIGURE_SCHEDULER_PRIORITY
> >> >>> >    #endif
> >> >>> > --
> >> >>> >
> >> >>> >
> -----------------------------------------------------------------------------------
> >> >>> > because your suggested patch gives this error:
> >> >>> >
> >> >>> >
> >> >>> >
> -----------------------------------------------------------------------------------
> >> >>> > In file included from
> >> >>> >
> /home/richi/quick-start/src/rtems/cpukit/include/rtems/confdefs/scheduler.h:64:0,
> >> >>> >                  from
> >> >>> >
> /home/richi/quick-start/src/rtems/cpukit/include/rtems/confdefs/threads.h:48,
> >> >>> >                  from
> >> >>> >
> /home/richi/quick-start/src/rtems/cpukit/include/rtems/confdefs/objectsposix.h:47,
> >> >>> >                  from
> >> >>> >
> /home/richi/quick-start/src/rtems/cpukit/include/rtems/confdefs.h:77,
> >> >>> >                  from
> >> >>> >
> /home/richi/quick-start/src/rtems/c/src/../../testsuites/samples/base_sp/system.h:39,
> >> >>> >                  from
> >> >>> >
> /home/richi/quick-start/src/rtems/c/src/../../testsuites/samples/base_sp/init.c:15:
> >> >>> >
> /home/richi/quick-start/src/rtems/cpukit/include/rtems/scheduler.h:260:37:
> >> >>> > error: 'CONFIGURE_MAXIMUM_PROCESSORS' undeclared here (not in a
> >> >>> > function); did you mean '_CONFIGURE_MAXIMUM_PROCESSORS'?
> >> >>> >        Scheduler_strong_APA_CPU CPU[ CONFIGURE_MAXIMUM_PROCESSORS
> ]; \
> >> >>> >                                      ^
> >> >>> >
> /home/richi/quick-start/src/rtems/cpukit/include/rtems/confdefs/scheduler.h:149:7:
> >> >>> > note: in expansion of macro 'RTEMS_SCHEDULER_STRONG_APA'
> >> >>> >        RTEMS_SCHEDULER_STRONG_APA( \
> >> >>> >        ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >> >>> >
> /home/richi/quick-start/src/rtems/cpukit/include/rtems/confdefs/scheduler.h:236:3:
> >> >>> > note: in expansion of macro 'CONFIGURE_SCHEDULER'
> >> >>> >    CONFIGURE_SCHEDULER;
> >> >>> >    ^~~~~~~~~~~~~~~~~~~
> >> >>> > Makefile:939: recipe for target 'base_sp/base_sp-init.o'
> >> >>> > failedp-init.o' failed
> >> >>> >
> >> >>> >
> -----------------------------------------------------------------------------------
> >> >>> >
> >> >>> > This is because single processor scheduler doesn't
> >> >>> > have CONFIGURE_MAXIMUM_PROCESSORS defined, So, would you like for
> me
> >> >>> > to make separate definition of CONFIGURE_SCHEDULER_STRONG_APA in
> >> >>> > cpukit/include/rtems/scheduler.h for a single processor system or
> does
> >> >>> > the current version that'd work only for SMP processor serve the
> purpose?
> >> >>>
> >> >>> Maybey add an
> >> >>>
> >> >>> #ifndef CONFIGURE_MAXIMUM_PROCESSORS
> >> >>>
> >> >>> #define CONFIGURE_MAXIMUM_PROCESSORS 1
> >> >>>
> >> >>> #endif
> >> >>>
> >> >>> before the default scheduler selection.
> >> >>>
> >> > _______________________________________________
> >> > devel mailing list
> >> > devel at rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200912/04f636c1/attachment.html>