On Tue, Jul 28, 2020 at 7:23 AM Richi Dubey <richidu...@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 <richidu...@gmail.com> wrote:
>>
>> 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
