Thanks, I changed the _Scheduler_Strong_APA_Get_lowest_scheduled to make it responsible for preempting and allocating the processors and doing the entire backtracking on its own.
On Tue, Aug 18, 2020 at 11:41 PM Gedare Bloom <ged...@rtems.org> wrote: > On Tue, Aug 18, 2020 at 11:20 AM Richi Dubey <richidu...@gmail.com> wrote: > > > > Hi, > > > > Thanks for the help. I looked at the call trace and figured out what is > wrong. > > > > As we had discussed earlier, We would be changing the passed variable > filter_base pointer (done here) to the function > _Scheduler_strong_Get_lowest_scheduled because after _Scheduler_SMP_Enqueue > calls the former function, it either (see code here) preempts the lowest > scheduled node and allocates the processor to node (filter_base) or for the > case lowest_scheduled has a higher priority (lower priority number) it > simply inserts the current node (or the filter_base) into the ready queue. > > > > When implementing the Strong_APA, the filter_node actually displaces the > higher priority node : > > > > Ex : > > A system with 2 CPUs, Tasks with lower task numbers have higher priority. > > > > T1: Allocated CPU 1. Affinity to both CPUs > > T3: Allocated CPU 2. Affinity to both CPUs > > > > T2: Just Arrived. Affinity only to CPU1. > > > > In this case, T2 would preempt T1 (A higher priority task) and T1 would > preempt T3. > > > > So, to make sure this works with our SMP framework, we had decided to > change/make filter_base point to T1 and lowest_scheduled to T3 after > preempting T2 preempts T1, after which SMP_Enqueue would preempt T3 and > schedule T1. > > > > But this is not working because when we change filter_base from > _Scheduler_strong_Get_lowest_scheduled (done here), the value of the node > in SMP_Enqueue does not get changed (Because it is a pass by value of > pointers). Also, there is no way to change the insert_priority variable in > SMP_Enqueue either. > > > > What should we do now? Can we change the SMP_Enqueue function to account > for the way Strong_APA behaves? > > > > No. Try to think through if you can solve this a different way. Maybe > you can store something in the context? > > > > > > > > > On Tue, Aug 18, 2020 at 9:40 PM Gedare Bloom <ged...@rtems.org> wrote: > >> > >> On Tue, Aug 18, 2020 at 9:21 AM Richi Dubey <richidu...@gmail.com> > wrote: > >> > > >> > Hi, > >> > > >> > This question is wrt the use of Scheduler_SMP_Preempt here. This > function eventually calls Allocate_Processor and while tracing with gdb, > everything is going as I planned, i.e. the correct node is getting > preempted and the caller to it is getting allocated the CPU. But, the test > fails here, because eventually the heir is not changed. > >> > > >> > Do I have to explicitly change the heir when I am trying to schedule > a node/thread on a different processor? Is doing SMP_Preempt not enough? > Please suggest. > >> > > >> The heir should get set (in SMP scheduling) by call to > >> _Thread_Dispatch_update_heir() from Allocate_Processor. Probably you > >> need to look at your allocate_processor hook. > >> > >> > Thanks, > >> > Richi. > >> > > >> > _______________________________________________ > >> > 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
