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
