[LITMUS^RT] litmus-dev Digest, Vol 79, Issue 2

[Ricardo Teixeira]

Hi Bjorn, thank you.

I am implementing a protocol based on MrsP, which involves the migration of
tasks, but the protocol does not contemplate the suspension of tasks. I
have not tried to reproduce this for the stock plugins. The plugin I'm
using was implemented by a colleague, it also involves the migration of
tasks.

I'll investigate what may be causing the tasks to be suspended. A starting
point could be the migration of tasks?

Best regards,

Ricardo

Em qui, 20 de dez de 2018 às 08:00, <litmus-dev-request at lists.litmus-rt.org>
escreveu:

> Send litmus-dev mailing list submissions to
>         litmus-dev at lists.litmus-rt.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.litmus-rt.org/listinfo/litmus-dev
> or, via email, send a message with subject or body 'help' to
>         litmus-dev-request at lists.litmus-rt.org
>
> You can reach the person managing the list at
>         litmus-dev-owner at lists.litmus-rt.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of litmus-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Zombie task after the experiment (Björn Brandenburg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 19 Dec 2018 15:24:43 +0100
> From: Björn Brandenburg <bbb at mpi-sws.org>
> To: litmus-dev at lists.litmus-rt.org
> Subject: Re: [LITMUS^RT] Zombie task after the experiment
> Message-ID: <73215C20-3A09-4664-B0CD-7AA99ED2AFCE at mpi-sws.org>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.bin
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
>
> ------------------------------
>
> End of litmus-dev Digest, Vol 79, Issue 2
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20181220/8397ce02/attachment.html>