[LITMUS^RT] litmus-dev Digest, Vol 81, Issue 7

Fri May 17 04:24:00 CEST 2019

Hi Björn,

UNLOCK overhead records continued to be incomplete, even without the -i
parameter. Debugging the ft2csv code, I noticed that it is coming out of
the loop in the statement below:

https://github.com/LITMUS-RT/feather-trace-tools/blob/master/src/ft2csv.c#L156

By modifying this piece of code, I was able to retrieve the records.

Best regards,

Ricardo

Em qui, 16 de mai de 2019 às 17:46, <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: P-RES: waking up tasks before timeout (Björn Brandenburg)
>    2. Re: litmus-dev Digest, Vol 81, Issue 5 (Björn Brandenburg)
>    3. Overheads (Martinez Garcia Jorge Luis (PS-EC/ESB2))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 16 May 2019 12:17:41 +0200
> From: Björn Brandenburg <bbb at mpi-sws.org>
> To: litmus-dev at lists.litmus-rt.org
> Subject: Re: [LITMUS^RT] P-RES: waking up tasks before timeout
> Message-ID: <55682065-9CC1-4992-8D9D-B2E45966C0CD at mpi-sws.org>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> > On 16. May 2019, at 11:32, Julien Haibach <julien.haibach at yahoo.de>
> wrote:
> >
> > currently I am working on a mode change implementation, on top of the
> P-RES plugin.
> > In the case of a mode change, tasks sleeping may need to be woken up
> before their previous mode release time.
> >
> > On job completion tasks are put asleep with
> > schedule_hrtimeout(&next_release, HRTIMER_MODE_ABS);
> > the task state is TASK_INTERRUPTIBLE - litmus/jobs.c:147
> >
> > So my question is what is the best way to wake up a sleeping task in
> this plugin?
> > I tried to call wake_up_process() from the plugin, but this did not work
> out of the box.
> >
>
> Hi Julien,
>
> these are standard Linux interfaces, so the regular methods apply. For
> instance, interruptible tasks can be woken up prematurely by a signal.
> Thus, presumably there are APIs for waking sleeping tasks early to
> implement signal delivery. I’d investigate that code path (or read through
> the various wake-up wrappers) to find the right API to use.
>
> Best,
> Björn
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 5061 bytes
> Desc: not available
> URL: <
> http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20190516/5f1a084b/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 2
> Date: Thu, 16 May 2019 12:21:52 +0200
> From: Björn Brandenburg <bbb at mpi-sws.org>
> To: litmus-dev at lists.litmus-rt.org
> Subject: Re: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 5
> Message-ID: <087E2F91-462C-460E-8165-EDECE0E6F4A0 at mpi-sws.org>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> > On 16. May 2019, at 04:16, Ricardo Teixeira <ricardo.btxr at gmail.com>
> wrote:
> >
> > The -x parameter did not bring the records relative to UNLOCK as you
> said. Looking at ftdump records, I noticed that the UNLOCK_START and
> UNLOCK_END records are interleaved by SCHED and SCHED2 records (see below).
> Could this be why these records are not being counted?
>
> Unless you are using the -i option, this should not make a difference.
>
> - Björn
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 5061 bytes
> Desc: not available
> URL: <
> http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20190516/51e8a3e0/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 3
> Date: Thu, 16 May 2019 20:45:23 +0000
> From: "Martinez Garcia Jorge Luis (PS-EC/ESB2)"
>         <JorgeLuis.MartinezGarcia at de.bosch.com>
> To: "litmus-dev at lists.litmus-rt.org" <litmus-dev at lists.litmus-rt.org>
> Subject: [LITMUS^RT] Overheads
> Message-ID: <f87dc7aaa9464c66b526b04f88bd9c0f at de.bosch.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Dear Björn,
> I'm currently trying to compare scheduling overheads under different
> schedulers. To that end, I would like to understand the overhead name
> convention used in Litmus. After computing some statistics by means of
> ft-compute-stats, I can see the following categories:   CXS, RELEASE,
> RELEASE-LATENCY, SCHED2, SCHED, and SEND-RESCHED.
> Please correct me, if I am wrong, I assume that CXS accounts for the
> overhead related to process switching (context-switch overhead) and SCHED +
> SCHED2 for process selection (scheduling overhead).
> Do RELEASE and RELEASE-LATENCY account for the execution of a release ISR
> (release overhead) and the delay until the release ISR starts execution
> (event latency)?
> What does SEND-RESCHED account for?
> Once a job is completed there is some kind of overhead involved like the
> one related to the trap generated by its completion, does this overhead
> fall under one of those categories?
> Best,
> Jorge
>
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20190516/dc200284/attachment.html
> >
>
> ------------------------------
>
> 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 81, Issue 7
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20190516/99e662b9/attachment.html>