Thank you for the clarification.
On Sat, Jul 18, 2020 at 9:06 PM Gedare Bloom <ged...@rtems.org> wrote:
> On Fri, Jul 17, 2020 at 2:22 AM Richi Dubey <richidu...@gmail.com> wrote:
> >>
> >>
> >> > 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?
> >
>
> I'm not 100% sure on this, but I believe it is because the thread's
> priority needs to be considered globally when taking
> scheduling/synchronization decisions.
>
> > On Wed, Jul 15, 2020 at 10:12 PM Gedare Bloom <ged...@rtems.org> wrote:
> >>
> >> On Wed, Jul 15, 2020 at 6:55 AM Richi Dubey <richidu...@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 <richidu...@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 <richidu...@gmail.com>
> wrote:
> >> >>>
> >> >>> I understand. Thank you.
> >> >>>
> >> >>> On Tue, Jul 14, 2020 at 7:05 PM Sebastian Huber <
> sebastian.hu...@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@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
