[LITMUS^RT] Zombie task after the experiment
Björn Brandenburg
bbb at mpi-sws.org
Wed Dec 19 15:24:43 CET 2018
Hi Ricardo,
> On 12. Dec 2018, at 03:10, Ricardo Teixeira <ricardo.btxr at gmail.com> wrote:
>
>
> I have been implementing a resource sharing protocol
which protocol? Does it involve task migration?
> for an existing multiprocessor scheduling algorithm in Litmus.
Which plugin are you using?
> Sometimes some tasks remain zombies after the time to stop the experiment. Debugging and investigating the logs, I noticed that these tasks pass through this code, inside kernel/sched/litmus.c
>
> /* check if the task became invalid while we dropped the lock */
> if (next && (!is_realtime(next) || !tsk_rt(next)->present)) {
> TRACE_TASK(next,
> "BAD: next (no longer?) valid\n");
> litmus->next_became_invalid(next);
> litmus_reschedule_local();
> next = NULL;
> }
>
> I noticed that the value of the attribute called "present" is 0 at that point.
This most likely means the plugin tried to schedule a task that is suspended. That should not be happening. Can you reliably reproduce this on a stock plugin?
> This condition can make the task zombie? What can make this value equals to 0 and how can I avoid it?
> The algorithm code does not set this value explicitly.
It’s set to zero when a task suspends. See here:
https://github.com/LITMUS-RT/litmus-rt/blob/4acc377593580e7d04ad8b42b258e8c2b39030ee/kernel/sched/litmus.c#L227
Regards,
Björn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5041 bytes
Desc: not available
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20181219/3058154c/attachment.bin>
More information about the litmus-dev
mailing list