Need help in understanding some of the existing code in RTEMS
Gedare Bloom
gedare at rtems.org
Tue Jul 28 15:12:51 UTC 2020
On Tue, Jul 28, 2020 at 7:23 AM Richi Dubey <richidubey at gmail.com> wrote:
>
> 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.
>
Names aren't really relevant, just something picked by someone. In
this case, I think it is short-hand for "action" -- sometimes we say a
timer triggers an action/event.
> 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
More information about the devel
mailing list