<div dir="ltr">Hi,<div><br></div><div>I do not have much expertise in timers. I was wondering what the name ACTN means/defines in the following context: </div><div><a href="https://git.rtems.org/rtems/tree/testsuites/smptests/smpschededf02/init.c#n368">https://git.rtems.org/rtems/tree/testsuites/smptests/smpschededf02/init.c#n368</a><br></div><div><br></div><div>Please let me know.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 22, 2020 at 6:46 PM Richi Dubey <<a href="mailto:richidubey@gmail.com">richidubey@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thank you for the clarification. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 18, 2020 at 9:06 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jul 17, 2020 at 2:22 AM Richi Dubey <<a href="mailto:richidubey@gmail.com" target="_blank">richidubey@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> > Scheduler_Node *nodes;<br>
>> > } Thread_Scheduler_control;<br>
>> ><br>
>> > 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?<br>
>> ><br>
>> See cpukit/score/src/threadinitialize.c +153<br>
><br>
><br>
> Thank you for your help.<br>
> /**<br>
> * @brief The scheduler nodes of this thread.<br>
> *<br>
> * Each thread has a scheduler node for each scheduler instance.<br>
> */<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
<br>
I'm not 100% sure on this, but I believe it is because the thread's<br>
priority needs to be considered globally when taking<br>
scheduling/synchronization decisions.<br>
<br>
> On Wed, Jul 15, 2020 at 10:12 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>><br>
>> On Wed, Jul 15, 2020 at 6:55 AM Richi Dubey <<a href="mailto:richidubey@gmail.com" target="_blank">richidubey@gmail.com</a>> wrote:<br>
>> ><br>
>> > Another quick question:<br>
>> > typedef struct {<br>
>> ><br>
>> > #if defined(RTEMS_SMP)<br>
>> > ...<br>
>> > Chain_Control Scheduler_nodes;<br>
>> ><br>
>> > #endif<br>
>> > /**<br>
>> > * @brief The scheduler nodes of this thread.<br>
>> > *<br>
>> > * Each thread has a scheduler node for each scheduler instance.<br>
>> > */<br>
>> > Scheduler_Node *nodes;<br>
>> > } Thread_Scheduler_control;<br>
>> ><br>
>> > 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?<br>
>> ><br>
>><br>
>> See cpukit/score/src/threadinitialize.c +153<br>
>><br>
>><br>
>> ><br>
>> > On Wed, Jul 15, 2020 at 5:57 PM Richi Dubey <<a href="mailto:richidubey@gmail.com" target="_blank">richidubey@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> I had a small question. The scheduler struct inside percpu.h looks like:<br>
>> >> ------------------------------------------------------------------------------------------------------<br>
>> >> struct {<br>
>> >> /**<br>
>> >> * @brief The scheduler control of the scheduler owning this processor.<br>
>> >> *<br>
>> >> * This pointer is NULL in case this processor is currently not used by a<br>
>> >> * scheduler instance.<br>
>> >> */<br>
>> >> const struct _Scheduler_Control *control;<br>
>> >><br>
>> >> /**<br>
>> >> * @brief The scheduler context of the scheduler owning this processor.<br>
>> >> *<br>
>> >> * This pointer is NULL in case this processor is currently not used by a<br>
>> >> * scheduler instance.<br>
>> >> */<br>
>> >> const struct Scheduler_Context *context;<br>
>> >><br>
>> >> /**<br>
>> >> * @brief The idle thread for this processor in case it is online and<br>
>> >> * currently not used by a scheduler instance.<br>
>> >> */<br>
>> >> struct _Thread_Control *idle_if_online_and_unused;<br>
>> >> } Scheduler;<br>
>> >> ------------------------------------------------------------------------------------------------------<br>
>> >> 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?<br>
>> >><br>
>><br>
>> Not exactly. What I understand is that:<br>
>> * When a processor is online (active), but not used by a scheduler,<br>
>> then it executes an idle task.<br>
>> * When a processor is online and used by a scheduler, it may be<br>
>> executing any task including an idle task.<br>
>><br>
>> You can find the relevant code in cpukit/include/rtems/score/schedulersmpimpl.h<br>
>><br>
>> The idle threads are specially handled when processors are<br>
>> added/removed from scheduler contexts. A scheduler keeps a chain of<br>
>> its idle threads:<br>
>> cpukit/include/rtems/score/schedulersmp.h +64<br>
>><br>
>> >> Please let me know,<br>
>> >> Thanks.<br>
>> >><br>
>> >> On Tue, Jul 14, 2020 at 8:28 PM Richi Dubey <<a href="mailto:richidubey@gmail.com" target="_blank">richidubey@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> I understand. Thank you.<br>
>> >>><br>
>> >>> On Tue, Jul 14, 2020 at 7:05 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>> >>>><br>
>> >>>> On 14/07/2020 13:37, Richi Dubey wrote:<br>
>> >>>><br>
>> >>>> > Here we remove the affine ready queue if it<br>
>> >>>> > exists from the chain of affine queues since now an affine thread is<br>
>> >>>> > scheduled on a processor.<br>
>> >>>> ><br>
>> >>>> > Why are we removing the entire affine queue corresponding to a<br>
>> >>>> > CPU when a single node of the queue gets scheduled?<br>
>> >>>> Because the highest priority affine thread is now a schedule one.<br>
>> ><br>
>> > _______________________________________________<br>
>> > devel mailing list<br>
>> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>
</blockquote></div>