How to schedule a node on a different processor?

Richi Dubey richidubey at gmail.com
Wed Aug 19 07:06:27 UTC 2020


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 <gedare at rtems.org> wrote:

> On Tue, Aug 18, 2020 at 11:20 AM Richi Dubey <richidubey at 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 <gedare at rtems.org> wrote:
> >>
> >> On Tue, Aug 18, 2020 at 9:21 AM Richi Dubey <richidubey at 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 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/20200819/8aed54d4/attachment.html>


More information about the devel mailing list