Need help in understanding some of the existing code in RTEMS

[Richi Dubey]

>
>
> >   Scheduler_Node *nodes;
> > } Thread_Scheduler_control;
> >
> > Why do we have a Scheduler_Node *nodes? What does it indicate? Since the
> pointer can point to a single value, why is it being called nodes?
> >
> See cpukit/score/src/threadinitialize.c +153


Thank you for your help.
/**
   * @brief The scheduler nodes of this thread.
   *
   * Each thread has a scheduler node for each scheduler instance.
   */

I went through the entire scheduler related code in threadinitialize.c and
I understood that the scheduler node which belongs to the scheduler that is
the home scheduler for a thread gets initialized with the thread's
priority, while other scheduler nodes gets initialized with the max
priority : for an idle thread case.

But why do we have a scheduler node for each scheduler instance? Is it
because the thread might migrate to a different processor to facilitate
helping and would need a node belonging to the scheduler instance which
owns the processor it is migrating to?

On Wed, Jul 15, 2020 at 10:12 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Wed, Jul 15, 2020 at 6:55 AM Richi Dubey <richidubey at gmail.com> wrote:
> >
> > Another quick question:
> > typedef struct {
> >
> > #if defined(RTEMS_SMP)
> > ...
> >   Chain_Control Scheduler_nodes;
> >
> > #endif
> > /**
> >    * @brief The scheduler nodes of this thread.
> >    *
> >    * Each thread has a scheduler node for each scheduler instance.
> >    */
> >   Scheduler_Node *nodes;
> > } Thread_Scheduler_control;
> >
> > Why do we have a Scheduler_Node *nodes? What does it indicate? Since the
> pointer can point to a single value, why is it being called nodes?
> >
>
> See cpukit/score/src/threadinitialize.c +153
>
>
> >
> > On Wed, Jul 15, 2020 at 5:57 PM Richi Dubey <richidubey at gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> I had a small question. The scheduler struct inside percpu.h looks like:
> >>
> ------------------------------------------------------------------------------------------------------
> >>     struct {
> >>       /**
> >>        * @brief The scheduler control of the scheduler owning this
> processor.
> >>        *
> >>        * This pointer is NULL in case this processor is currently not
> used by a
> >>        * scheduler instance.
> >>        */
> >>       const struct _Scheduler_Control *control;
> >>
> >>       /**
> >>        * @brief The scheduler context of the scheduler owning this
> processor.
> >>        *
> >>        * This pointer is NULL in case this processor is currently not
> used by a
> >>        * scheduler instance.
> >>        */
> >>       const struct Scheduler_Context *context;
> >>
> >>       /**
> >>        * @brief The idle thread for this processor in case it is online
> and
> >>        * currently not used by a scheduler instance.
> >>        */
> >>       struct _Thread_Control *idle_if_online_and_unused;
> >>     } Scheduler;
> >>
> ------------------------------------------------------------------------------------------------------
> >> So, does this mean a CPU when active is always either executing an idle
> thread and is not being used by a scheduler (so has a thread attribute in
> the idle_if_online_and_unused), or is used by a scheduler and is executing
> a task ( which can not be an idle task)? Another equivalent question is do
> we have an idle scheduler node, like we have idle predefined threads that
> run on a CPU?
> >>
>
> Not exactly. What I understand is that:
> * When a processor is online (active), but not used by a scheduler,
> then it executes an idle task.
> * When a processor is online and used by a scheduler, it may be
> executing any task including an idle task.
>
> You can find the relevant code in
> cpukit/include/rtems/score/schedulersmpimpl.h
>
> The idle threads are specially handled when processors are
> added/removed from scheduler contexts. A scheduler keeps a chain of
> its idle threads:
> cpukit/include/rtems/score/schedulersmp.h +64
>
> >> Please let me know,
> >> Thanks.
> >>
> >> On Tue, Jul 14, 2020 at 8:28 PM Richi Dubey <richidubey at gmail.com>
> wrote:
> >>>
> >>> I understand. Thank you.
> >>>
> >>> On Tue, Jul 14, 2020 at 7:05 PM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
> >>>>
> >>>> On 14/07/2020 13:37, Richi Dubey wrote:
> >>>>
> >>>> >     Here we remove the affine ready queue if it
> >>>> >     exists from the chain of affine queues since now an affine
> thread is
> >>>> >     scheduled on a processor.
> >>>> >
> >>>> > Why are we removing the entire affine queue corresponding to a
> >>>> > CPU when a single node of the queue gets scheduled?
> >>>> Because the highest priority affine thread is now a schedule one.
> >
> > _______________________________________________
> > 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/20200717/dd9f9035/attachment-0001.html>