[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