Need help in understanding some of the existing code in RTEMS

[Richi Dubey]

Hi,

I do not have much expertise in timers. I was wondering what the name ACTN
means/defines in the following context:
https://git.rtems.org/rtems/tree/testsuites/smptests/smpschededf02/init.c#n368

Please let me know.

On Wed, Jul 22, 2020 at 6:46 PM Richi Dubey <richidubey at gmail.com> wrote:

> Thank you for the clarification.
>
> On Sat, Jul 18, 2020 at 9:06 PM Gedare Bloom <gedare at rtems.org> wrote:
>
>> On Fri, Jul 17, 2020 at 2:22 AM Richi Dubey <richidubey at 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 <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/20200728/ec932bd0/attachment.html>