[LITMUS^RT] Base_task when executed does not give the correct debug output as rtspin does

Susan S susanrosethomas2001 at gmail.com
Thu Mar 15 06:28:57 CET 2018


Hi,

Thank you so much for pointing out the error.



On Wed, Mar 14, 2018 at 3:40 PM, Björn Brandenburg <bbb at mpi-sws.org> wrote:

> > On 14. Mar 2018, at 06:38, Susan S <susanrosethomas2001 at gmail.com>
> wrote:
> >
> > Hi,
> >
> > Please do let me know why the st-trace-schedule output does not give the
> all the cpus actually used for the base_task.
> >
> > Regards,
> > Susan Rose.
>
> Short answer: st-trace-schedule shows only tasks that are in the
> SCHED_LITMUS scheduling class (i.e., real-time tasks admitted by LITMUS^RT).
>
> Slightly longer answer: Your code calls fork in every *job* of the task.
> This is highly inefficient and not suitable for real-time tasks. Also,
> under most LITMUS^RT plugins, when a real-time task forks, the forked child
> is NOT automatically admitted as a LITMUS^RT task — you need to that
> explicitly from the parent task if you really want the child task to become
> a real-time task as well. The rationale for this behavior is that one could
> otherwise easily overload the system with accidental forks.
>
> However, for what you are trying to accomplish, you should definitely not
> fork in every job release. If you want tasks on all cores, you should
> launch the appropriate number of *sequential* tasks from a shell script. If
> you want a task with real-time threads, you should spawn the threads during
> initialization of the program, before entering real-time mode, and then
> transition each thread into real-time mode after it has migrated to the
> appropriate core.
>
> - Björn
>
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20180315/cd986ca7/attachment.html>


More information about the litmus-dev mailing list