From sobhan.niknam at yahoo.com Fri Feb 1 14:38:54 2019 From: sobhan.niknam at yahoo.com (sobhan niknam) Date: Fri, 1 Feb 2019 14:38:54 +0100 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 Message-ID: Dear All, I followed this instruction step by step to install LITMUS RT on Ubuntu 14.04.1 LTS on Odroid XU4 platform. However, my linux doesn’t have grub for configuring the boot loader. Instead, according to my search, the ARM-based embedded systems have u-boot. Can anybody tell me how I can configure the boot loader to show the LITMUS RT kernel in the boot menu? I look forward to hearing from you very soon. Best Regards, Sobhan Niknam ———————————————————————— Sobhan Niknam PhD student, Leiden Embedded Research Center (LERC), Leiden Institute of Advanced Computer Science (LIACS), Leiden University -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Fri Feb 1 14:44:15 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Fri, 1 Feb 2019 14:44:15 +0100 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: References: Message-ID: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> Dear Sobhan, > On 1. Feb 2019, at 14:38, sobhan niknam wrote: > > I followed this instruction step by step to install LITMUS RT on Ubuntu 14.04.1 LTS on Odroid XU4 platform. Those instructions assume an x86 platform. > However, my linux doesn’t have grub for configuring the boot loader. Instead, according to my search, the ARM-based embedded systems have u-boot. Indeed, that’s correct. > Can anybody tell me how I can configure the boot loader to show the LITMUS RT kernel in the boot menu? > I look forward to hearing from you very soon. We don’t have ready-to-go instructions for configuring uboot (feel free to contribute a guide!), this often depends very much on your specific SoC and your distro / vendor config. In the past, I’ve had luck with setting up tftp boot. My suggestion would be to google for instructions for configuring the Odroid XU4 to boot via tftp. 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: From ricardo.btxr at gmail.com Sat May 11 18:19:47 2019 From: ricardo.btxr at gmail.com (Ricardo Teixeira) Date: Sat, 11 May 2019 13:19:47 -0300 Subject: [LITMUS^RT] Schedule and Locking Overhead information Message-ID: Hi, I executed 800 experiments for an out of stock protocol, each experiment runned for 30 seconds. During the experiments, I got overhead information using the scripts disponible at github (throught the feather trace tools). I also ran the same set of experiments for another out of stock protocol and got the same overhead information. Both protocols generates nearly the same amount of jobs. Analysing the collected data, I realized that the second protocol generated about 3 times more samples than the first, for all types of data collected, for example: CXS, LOCK, RELEASE-LATENCY, RELEASE, SCHED and SCHED2. Another problem was that both protocols gererated a reasonable amount of LOCK samples, but an insignificant amount of UNLOCK samples. For example: for an subset of 100 experiments, there was 62k LOCK samples for the first protocol and 177k for the second, there was 0 UNLOCK samples for the first protocol and 6 for the second. That situation was present in all of the 8 subsets, where the amount of UNLOCK samples was never above 10 for both protocols. Through the tracers, I known that the LOCK and UNLOCK operations were happening as expected and I not changed the code which saves the overhead tracers. Could anyone help me to understand what is happening? Thanks, Ricardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Sun May 12 12:25:28 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Sun, 12 May 2019 12:25:28 +0200 Subject: [LITMUS^RT] Schedule and Locking Overhead information In-Reply-To: References: Message-ID: <4BC7E4D9-76B5-446C-A4AA-5EE704826FF5@mpi-sws.org> > On 11. May 2019, at 18:19, Ricardo Teixeira wrote: > > I executed 800 experiments for an out of stock protocol, each experiment runned for 30 seconds. During the experiments, I got overhead information using the scripts disponible at github (throught the feather trace tools). > > I also ran the same set of experiments for another out of stock protocol and got the same overhead information. Both protocols generates nearly the same amount of jobs. > > Analysing the collected data, I realized that the second protocol generated about 3 times more samples than the first, for all types of data collected, for example: CXS, LOCK, RELEASE-LATENCY, RELEASE, SCHED and SCHED2. Hi Ricardo, some variation in the number of scheduling decisions and context switches can be expected, especially if you are comparing different scheduling and/or locking policies, but release-related events are determined solely by the workloads, so if you are running the same workload under both setups, it shouldn’t differ by a factor of three. > > Another problem was that both protocols gererated a reasonable amount of LOCK samples, but an insignificant amount of UNLOCK samples. That’s very strange — the operations should obviously be symmetric and hence produce an equal number of samples. > For example: for an subset of 100 experiments, there was 62k LOCK samples for the first protocol and 177k for the second, there was 0 UNLOCK samples for the first protocol and 6 for the second. That situation was present in all of the 8 subsets, where the amount of UNLOCK samples was never above 10 for both protocols. > > Through the tracers, I known that the LOCK and UNLOCK operations were happening as expected and I not changed the code which saves the overhead tracers. > > Could anyone help me to understand what is happening? Did you see any messages about failed writes to the trace buffers? - Björn -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5061 bytes Desc: not available URL: From ricardo.btxr at gmail.com Mon May 13 15:06:09 2019 From: ricardo.btxr at gmail.com (Ricardo Teixeira) Date: Mon, 13 May 2019 10:06:09 -0300 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 2 In-Reply-To: References: Message-ID: Hi Björn, Thanks. The two experiments are for the same algorithm, what changes is the resource sharing protocol. The workload is the same for both experiments. The suspicion I had is that in one of the experiments data is being collected from only 1 of the processors, but I have not yet confirmed this suspicion. I think I noticed this at some point when running ft-dump for one of the protocols, but this was some time ago. As soon as possible, I'm going to run the ft-dump again for both cases. I will also check the event codes used when saving and reading the tracers for overhead, maybe something has been changed by the precursor works. There are no error messages for recording the tracers at the end of the experiments. Best regards, Ricardo Em seg, 13 de mai de 2019 às 07:01, 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: Schedule and Locking Overhead information (Björn Brandenburg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 12 May 2019 12:25:28 +0200 > From: Björn Brandenburg > To: litmus-dev at lists.litmus-rt.org > Subject: Re: [LITMUS^RT] Schedule and Locking Overhead information > Message-ID: <4BC7E4D9-76B5-446C-A4AA-5EE704826FF5 at mpi-sws.org> > Content-Type: text/plain; charset="utf-8" > > > On 11. May 2019, at 18:19, Ricardo Teixeira > wrote: > > > > I executed 800 experiments for an out of stock protocol, each experiment > runned for 30 seconds. During the experiments, I got overhead information > using the scripts disponible at github (throught the feather trace tools). > > > > I also ran the same set of experiments for another out of stock protocol > and got the same overhead information. Both protocols generates nearly the > same amount of jobs. > > > > Analysing the collected data, I realized that the second protocol > generated about 3 times more samples than the first, for all types of data > collected, for example: CXS, LOCK, RELEASE-LATENCY, RELEASE, SCHED and > SCHED2. > > Hi Ricardo, > > some variation in the number of scheduling decisions and context switches > can be expected, especially if you are comparing different scheduling > and/or locking policies, but release-related events are determined solely > by the workloads, so if you are running the same workload under both > setups, it shouldn’t differ by a factor of three. > > > > > Another problem was that both protocols gererated a reasonable amount of > LOCK samples, but an insignificant amount of UNLOCK samples. > > That’s very strange — the operations should obviously be symmetric and > hence produce an equal number of samples. > > > For example: for an subset of 100 experiments, there was 62k LOCK > samples for the first protocol and 177k for the second, there was 0 UNLOCK > samples for the first protocol and 6 for the second. That situation was > present in all of the 8 subsets, where the amount of UNLOCK samples was > never above 10 for both protocols. > > > > Through the tracers, I known that the LOCK and UNLOCK operations were > happening as expected and I not changed the code which saves the overhead > tracers. > > > > Could anyone help me to understand what is happening? > > Did you see any messages about failed writes to the trace buffers? > > - 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/20190512/f5abda71/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 81, Issue 2 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Mon May 13 15:45:39 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Mon, 13 May 2019 15:45:39 +0200 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 2 In-Reply-To: References: Message-ID: > On 13. May 2019, at 15:06, Ricardo Teixeira wrote: > > There are no error messages for recording the tracers at the end of the experiments. > Please check the kernel messages: if there are no errors, then there should be a message that states that there were zero missed writes. In no case should there be *no* messages. - Björn -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5061 bytes Desc: not available URL: From ricardo.btxr at gmail.com Tue May 14 05:32:34 2019 From: ricardo.btxr at gmail.com (Ricardo Teixeira) Date: Tue, 14 May 2019 00:32:34 -0300 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 2 In-Reply-To: References: Message-ID: Hi Björn, Looking at the UNLOCK events through ftdump, I noticed that almost all UNLOCK_START records are generated with IRQ enabled. The scripts I'm using generated only one ft.bin file, I got those scripts from another work based on an old Litmus version. When I ran the ftdump for this file I saw events from only one CPU. Att., Ricardo Em seg, 13 de mai de 2019 às 10:06, Ricardo Teixeira escreveu: > Hi Björn, > > Thanks. > > The two experiments are for the same algorithm, what changes is the > resource sharing protocol. The workload is the same for both experiments. > > The suspicion I had is that in one of the experiments data is being > collected from only 1 of the processors, but I have not yet confirmed this > suspicion. I think I noticed this at some point when running ft-dump for > one of the protocols, but this was some time ago. As soon as possible, I'm > going to run the ft-dump again for both cases. > > I will also check the event codes used when saving and reading the tracers > for overhead, maybe something has been changed by the precursor works. > > There are no error messages for recording the tracers at the end of the > experiments. > > Best regards, > > Ricardo > > Em seg, 13 de mai de 2019 às 07:01, < > 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: Schedule and Locking Overhead information (Björn Brandenburg) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sun, 12 May 2019 12:25:28 +0200 >> From: Björn Brandenburg >> To: litmus-dev at lists.litmus-rt.org >> Subject: Re: [LITMUS^RT] Schedule and Locking Overhead information >> Message-ID: <4BC7E4D9-76B5-446C-A4AA-5EE704826FF5 at mpi-sws.org> >> Content-Type: text/plain; charset="utf-8" >> >> > On 11. May 2019, at 18:19, Ricardo Teixeira >> wrote: >> > >> > I executed 800 experiments for an out of stock protocol, each >> experiment runned for 30 seconds. During the experiments, I got overhead >> information using the scripts disponible at github (throught the feather >> trace tools). >> > >> > I also ran the same set of experiments for another out of stock >> protocol and got the same overhead information. Both protocols generates >> nearly the same amount of jobs. >> > >> > Analysing the collected data, I realized that the second protocol >> generated about 3 times more samples than the first, for all types of data >> collected, for example: CXS, LOCK, RELEASE-LATENCY, RELEASE, SCHED and >> SCHED2. >> >> Hi Ricardo, >> >> some variation in the number of scheduling decisions and context switches >> can be expected, especially if you are comparing different scheduling >> and/or locking policies, but release-related events are determined solely >> by the workloads, so if you are running the same workload under both >> setups, it shouldn’t differ by a factor of three. >> >> > >> > Another problem was that both protocols gererated a reasonable amount >> of LOCK samples, but an insignificant amount of UNLOCK samples. >> >> That’s very strange — the operations should obviously be symmetric and >> hence produce an equal number of samples. >> >> > For example: for an subset of 100 experiments, there was 62k LOCK >> samples for the first protocol and 177k for the second, there was 0 UNLOCK >> samples for the first protocol and 6 for the second. That situation was >> present in all of the 8 subsets, where the amount of UNLOCK samples was >> never above 10 for both protocols. >> > >> > Through the tracers, I known that the LOCK and UNLOCK operations were >> happening as expected and I not changed the code which saves the overhead >> tracers. >> > >> > Could anyone help me to understand what is happening? >> >> Did you see any messages about failed writes to the trace buffers? >> >> - 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/20190512/f5abda71/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 81, Issue 2 >> ***************************************** >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricardo.btxr at gmail.com Wed May 15 02:31:22 2019 From: ricardo.btxr at gmail.com (Ricardo Teixeira) Date: Tue, 14 May 2019 21:31:22 -0300 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 3 In-Reply-To: References: Message-ID: Hi, Below are the kernel messages for the overhead and schedule tracers. When I'm looking for UNLOCK events through ftdump, I noticed that almost all UNLOCK_START records are generated with IRQ enabled for both protocols I'm running. Is this why these records are not being counted? Is there any parameter so I can collect these records? [ 397.294157] Enabling feather-trace event 501. [ 397.294174] Enabling feather-trace event 502. [ 397.294180] Enabling feather-trace event 503. [ 397.294185] Enabling feather-trace event 504. [ 397.294190] Enabling feather-trace event 505. [ 397.294195] Enabling feather-trace event 506. [ 397.294197] Enabling feather-trace event 501. [ 397.294204] Enabling feather-trace event 502. [ 397.294206] Enabling feather-trace event 503. [ 397.294208] Enabling feather-trace event 504. [ 397.294210] Enabling feather-trace event 505. [ 397.294211] Enabling feather-trace event 506. [ 397.294213] Enabling feather-trace event 507. [ 397.294215] Enabling feather-trace event 508. [ 397.294216] Enabling feather-trace event 509. [ 397.294218] Enabling feather-trace event 510. [ 397.294220] Enabling feather-trace event 511. [ 397.294221] Enabling feather-trace event 512. [ 397.294232] Enabling feather-trace event 501. [ 397.294241] Enabling feather-trace event 501. [ 397.294249] Enabling feather-trace event 507. [ 397.294256] Enabling feather-trace event 502. [ 397.294260] Enabling feather-trace event 503. [ 397.294265] Enabling feather-trace event 502. [ 397.294271] Enabling feather-trace event 508. [ 397.294276] Enabling feather-trace event 509. [ 397.294278] Enabling feather-trace event 504. [ 397.294282] Enabling feather-trace event 505. [ 397.294288] Enabling feather-trace event 506. [ 397.294292] Enabling feather-trace event 503. [ 397.294296] Enabling feather-trace event 504. [ 397.294298] Enabling feather-trace event 505. [ 397.294299] Enabling feather-trace event 506. [ 397.294301] Enabling feather-trace event 507. [ 397.294303] Enabling feather-trace event 508. [ 397.294304] Enabling feather-trace event 509. [ 397.294306] Enabling feather-trace event 510. [ 397.294307] Enabling feather-trace event 511. [ 397.294309] Enabling feather-trace event 512. [ 397.294355] Enabling feather-trace event 510. [ 397.294380] Enabling feather-trace event 511. [ 397.294382] Enabling feather-trace event 512. [ 397.294413] Enabling feather-trace event 507. [ 397.294438] Enabling feather-trace event 508. [ 397.294440] Enabling feather-trace event 509. [ 397.294441] Enabling feather-trace event 510. [ 397.294443] Enabling feather-trace event 511. [ 397.294445] Enabling feather-trace event 512. [ 401.807149] get_inode_obj(ffff90f9523bab08, 6, 0): couldn't find object [ 401.807153] alloc_inode_obj(ffff90f9523bab08, 6, 0): object created [ 401.812229] get_inode_obj(ffff90f9523bab08, 6, 1): couldn't find object [ 401.812231] alloc_inode_obj(ffff90f9523bab08, 6, 1): object created [ 401.817405] get_inode_obj(ffff90f9523bab08, 6, 2): couldn't find object [ 401.817407] alloc_inode_obj(ffff90f9523bab08, 6, 2): object created [ 401.821408] get_inode_obj(ffff90f9523bab08, 6, 3): couldn't find object [ 401.821410] alloc_inode_obj(ffff90f9523bab08, 6, 3): object created [ 402.827423] time stamp buffer: trying to allocate 134217728 time stamps for minor=0. [ 403.047259] Enabling feather-trace event 100. [ 403.047263] Enabling feather-trace event 101. [ 403.047265] Enabling feather-trace event 106. [ 403.047266] Enabling feather-trace event 107. [ 403.047268] Enabling feather-trace event 102. [ 403.047270] Enabling feather-trace event 103. [ 403.047271] Enabling feather-trace event 110. [ 403.047273] Enabling feather-trace event 111. [ 403.047274] Enabling feather-trace event 104. [ 403.047276] Enabling feather-trace event 105. [ 403.047278] Enabling feather-trace event 30. [ 403.047279] Enabling feather-trace event 31. [ 403.047281] Enabling feather-trace event 40. [ 403.047282] Enabling feather-trace event 41. [ 403.047284] Enabling feather-trace event 208. [ 435.399890] Disabling feather-trace event 100. [ 435.399893] Disabling feather-trace event 101. [ 435.399895] Disabling feather-trace event 106. [ 435.399896] Disabling feather-trace event 107. [ 435.399897] Disabling feather-trace event 102. [ 435.399898] Disabling feather-trace event 103. [ 435.399900] Disabling feather-trace event 110. [ 435.399901] Disabling feather-trace event 111. [ 435.399902] Disabling feather-trace event 104. [ 435.399903] Disabling feather-trace event 105. [ 435.399904] Disabling feather-trace event 30. [ 435.399906] Disabling feather-trace event 31. [ 435.399907] Disabling feather-trace event 40. [ 435.399908] Disabling feather-trace event 41. [ 435.399909] Disabling feather-trace event 208. [ 436.441046] Failed trace writes: 0 [ 436.537011] Disabling feather-trace event 501. [ 436.537012] Disabling feather-trace event 501. [ 436.537013] Disabling feather-trace event 501. [ 436.537033] Disabling feather-trace event 502. [ 436.537034] Disabling feather-trace event 502. [ 436.537036] Disabling feather-trace event 503. [ 436.537037] Disabling feather-trace event 503. [ 436.537039] Disabling feather-trace event 504. [ 436.537040] Disabling feather-trace event 504. [ 436.537050] Disabling feather-trace event 505. [ 436.537051] Disabling feather-trace event 502. [ 436.537052] Disabling feather-trace event 503. [ 436.537053] Disabling feather-trace event 506. [ 436.537054] Disabling feather-trace event 505. [ 436.537055] Disabling feather-trace event 504. [ 436.537055] Disabling feather-trace event 507. [ 436.537056] Disabling feather-trace event 505. [ 436.537057] Disabling feather-trace event 508. [ 436.537058] Disabling feather-trace event 506. [ 436.537059] Disabling feather-trace event 509. [ 436.537060] Disabling feather-trace event 506. [ 436.537061] Disabling feather-trace event 507. [ 436.537062] Disabling feather-trace event 507. [ 436.537063] Disabling feather-trace event 510. [ 436.537063] Disabling feather-trace event 508. [ 436.537064] Disabling feather-trace event 508. [ 436.537065] Disabling feather-trace event 509. [ 436.537066] Disabling feather-trace event 511. [ 436.537067] Disabling feather-trace event 512. [ 436.537074] Disabling feather-trace event 509. [ 436.537077] Disabling feather-trace event 510. [ 436.537078] Disabling feather-trace event 510. [ 436.537079] Disabling feather-trace event 511. [ 436.537080] Disabling feather-trace event 511. [ 436.537081] Disabling feather-trace event 512. [ 436.537083] Disabling feather-trace event 512. [ 436.537505] Disabling feather-trace event 501. [ 436.537507] Disabling feather-trace event 502. [ 436.537509] Disabling feather-trace event 503. [ 436.537511] Disabling feather-trace event 504. [ 436.537513] Disabling feather-trace event 505. [ 436.537515] Disabling feather-trace event 506. [ 436.537516] Disabling feather-trace event 507. [ 436.537518] Disabling feather-trace event 508. [ 436.537520] Disabling feather-trace event 509. [ 436.537522] Disabling feather-trace event 510. [ 436.537524] Disabling feather-trace event 511. [ 436.537525] Disabling feather-trace event 512. [ 437.592942] Failed trace writes: 0 [ 437.592943] Failed trace writes: 0 [ 437.592944] Failed trace writes: 0 [ 437.593619] Failed trace writes: 0 [ 437.594147] sched_trace kfifo released > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricardo.btxr at gmail.com Wed May 15 02:44:54 2019 From: ricardo.btxr at gmail.com (Ricardo Teixeira) Date: Tue, 14 May 2019 21:44:54 -0300 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 3 In-Reply-To: References: Message-ID: Hi, I think this information can be useful also. ft.bin LOCK >> ft_overhead=LOCK.float32 Generating binary, NumPy-compatible output. Total : 42020 Skipped : 1169 Avoided : 0 Complete : 983 Incomplete : 0 Non RT : 0 Interleaved : 0 Interrupted : 0 ft.bin UNLOCK >> ft_overhead=UNLOCK.float32 Generating binary, NumPy-compatible output. Total : 42020 Skipped : 1175 Avoided : 0 Complete : 0 Incomplete : 983 Non RT : 0 Interleaved : 0 Interrupted : 0 Best regards, Ricardo Em ter, 14 de mai de 2019 às 21:31, Ricardo Teixeira escreveu: > Hi, > > Below are the kernel messages for the overhead and schedule tracers. > > When I'm looking for UNLOCK events through ftdump, I noticed that almost > all UNLOCK_START records are generated with IRQ enabled for both protocols > I'm running. Is this why these records are not being counted? Is there any > parameter so I can collect these records? > > [ 397.294157] Enabling feather-trace event 501. > [ 397.294174] Enabling feather-trace event 502. > [ 397.294180] Enabling feather-trace event 503. > [ 397.294185] Enabling feather-trace event 504. > [ 397.294190] Enabling feather-trace event 505. > [ 397.294195] Enabling feather-trace event 506. > [ 397.294197] Enabling feather-trace event 501. > [ 397.294204] Enabling feather-trace event 502. > [ 397.294206] Enabling feather-trace event 503. > [ 397.294208] Enabling feather-trace event 504. > [ 397.294210] Enabling feather-trace event 505. > [ 397.294211] Enabling feather-trace event 506. > [ 397.294213] Enabling feather-trace event 507. > [ 397.294215] Enabling feather-trace event 508. > [ 397.294216] Enabling feather-trace event 509. > [ 397.294218] Enabling feather-trace event 510. > [ 397.294220] Enabling feather-trace event 511. > [ 397.294221] Enabling feather-trace event 512. > [ 397.294232] Enabling feather-trace event 501. > [ 397.294241] Enabling feather-trace event 501. > [ 397.294249] Enabling feather-trace event 507. > [ 397.294256] Enabling feather-trace event 502. > [ 397.294260] Enabling feather-trace event 503. > [ 397.294265] Enabling feather-trace event 502. > [ 397.294271] Enabling feather-trace event 508. > [ 397.294276] Enabling feather-trace event 509. > [ 397.294278] Enabling feather-trace event 504. > [ 397.294282] Enabling feather-trace event 505. > [ 397.294288] Enabling feather-trace event 506. > [ 397.294292] Enabling feather-trace event 503. > [ 397.294296] Enabling feather-trace event 504. > [ 397.294298] Enabling feather-trace event 505. > [ 397.294299] Enabling feather-trace event 506. > [ 397.294301] Enabling feather-trace event 507. > [ 397.294303] Enabling feather-trace event 508. > [ 397.294304] Enabling feather-trace event 509. > [ 397.294306] Enabling feather-trace event 510. > [ 397.294307] Enabling feather-trace event 511. > [ 397.294309] Enabling feather-trace event 512. > [ 397.294355] Enabling feather-trace event 510. > [ 397.294380] Enabling feather-trace event 511. > [ 397.294382] Enabling feather-trace event 512. > [ 397.294413] Enabling feather-trace event 507. > [ 397.294438] Enabling feather-trace event 508. > [ 397.294440] Enabling feather-trace event 509. > [ 397.294441] Enabling feather-trace event 510. > [ 397.294443] Enabling feather-trace event 511. > [ 397.294445] Enabling feather-trace event 512. > [ 401.807149] get_inode_obj(ffff90f9523bab08, 6, 0): couldn't find object > [ 401.807153] alloc_inode_obj(ffff90f9523bab08, 6, 0): object created > [ 401.812229] get_inode_obj(ffff90f9523bab08, 6, 1): couldn't find object > [ 401.812231] alloc_inode_obj(ffff90f9523bab08, 6, 1): object created > [ 401.817405] get_inode_obj(ffff90f9523bab08, 6, 2): couldn't find object > [ 401.817407] alloc_inode_obj(ffff90f9523bab08, 6, 2): object created > [ 401.821408] get_inode_obj(ffff90f9523bab08, 6, 3): couldn't find object > [ 401.821410] alloc_inode_obj(ffff90f9523bab08, 6, 3): object created > [ 402.827423] time stamp buffer: trying to allocate 134217728 time stamps > for minor=0. > [ 403.047259] Enabling feather-trace event 100. > [ 403.047263] Enabling feather-trace event 101. > [ 403.047265] Enabling feather-trace event 106. > [ 403.047266] Enabling feather-trace event 107. > [ 403.047268] Enabling feather-trace event 102. > [ 403.047270] Enabling feather-trace event 103. > [ 403.047271] Enabling feather-trace event 110. > [ 403.047273] Enabling feather-trace event 111. > [ 403.047274] Enabling feather-trace event 104. > [ 403.047276] Enabling feather-trace event 105. > [ 403.047278] Enabling feather-trace event 30. > [ 403.047279] Enabling feather-trace event 31. > [ 403.047281] Enabling feather-trace event 40. > [ 403.047282] Enabling feather-trace event 41. > [ 403.047284] Enabling feather-trace event 208. > [ 435.399890] Disabling feather-trace event 100. > [ 435.399893] Disabling feather-trace event 101. > [ 435.399895] Disabling feather-trace event 106. > [ 435.399896] Disabling feather-trace event 107. > [ 435.399897] Disabling feather-trace event 102. > [ 435.399898] Disabling feather-trace event 103. > [ 435.399900] Disabling feather-trace event 110. > [ 435.399901] Disabling feather-trace event 111. > [ 435.399902] Disabling feather-trace event 104. > [ 435.399903] Disabling feather-trace event 105. > [ 435.399904] Disabling feather-trace event 30. > [ 435.399906] Disabling feather-trace event 31. > [ 435.399907] Disabling feather-trace event 40. > [ 435.399908] Disabling feather-trace event 41. > [ 435.399909] Disabling feather-trace event 208. > [ 436.441046] Failed trace writes: 0 > [ 436.537011] Disabling feather-trace event 501. > [ 436.537012] Disabling feather-trace event 501. > [ 436.537013] Disabling feather-trace event 501. > [ 436.537033] Disabling feather-trace event 502. > [ 436.537034] Disabling feather-trace event 502. > [ 436.537036] Disabling feather-trace event 503. > [ 436.537037] Disabling feather-trace event 503. > [ 436.537039] Disabling feather-trace event 504. > [ 436.537040] Disabling feather-trace event 504. > [ 436.537050] Disabling feather-trace event 505. > [ 436.537051] Disabling feather-trace event 502. > [ 436.537052] Disabling feather-trace event 503. > [ 436.537053] Disabling feather-trace event 506. > [ 436.537054] Disabling feather-trace event 505. > [ 436.537055] Disabling feather-trace event 504. > [ 436.537055] Disabling feather-trace event 507. > [ 436.537056] Disabling feather-trace event 505. > [ 436.537057] Disabling feather-trace event 508. > [ 436.537058] Disabling feather-trace event 506. > [ 436.537059] Disabling feather-trace event 509. > [ 436.537060] Disabling feather-trace event 506. > [ 436.537061] Disabling feather-trace event 507. > [ 436.537062] Disabling feather-trace event 507. > [ 436.537063] Disabling feather-trace event 510. > [ 436.537063] Disabling feather-trace event 508. > [ 436.537064] Disabling feather-trace event 508. > [ 436.537065] Disabling feather-trace event 509. > [ 436.537066] Disabling feather-trace event 511. > [ 436.537067] Disabling feather-trace event 512. > [ 436.537074] Disabling feather-trace event 509. > [ 436.537077] Disabling feather-trace event 510. > [ 436.537078] Disabling feather-trace event 510. > [ 436.537079] Disabling feather-trace event 511. > [ 436.537080] Disabling feather-trace event 511. > [ 436.537081] Disabling feather-trace event 512. > [ 436.537083] Disabling feather-trace event 512. > [ 436.537505] Disabling feather-trace event 501. > [ 436.537507] Disabling feather-trace event 502. > [ 436.537509] Disabling feather-trace event 503. > [ 436.537511] Disabling feather-trace event 504. > [ 436.537513] Disabling feather-trace event 505. > [ 436.537515] Disabling feather-trace event 506. > [ 436.537516] Disabling feather-trace event 507. > [ 436.537518] Disabling feather-trace event 508. > [ 436.537520] Disabling feather-trace event 509. > [ 436.537522] Disabling feather-trace event 510. > [ 436.537524] Disabling feather-trace event 511. > [ 436.537525] Disabling feather-trace event 512. > [ 437.592942] Failed trace writes: 0 > [ 437.592943] Failed trace writes: 0 > [ 437.592944] Failed trace writes: 0 > [ 437.593619] Failed trace writes: 0 > [ 437.594147] sched_trace kfifo released > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Wed May 15 09:30:12 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Wed, 15 May 2019 09:30:12 +0200 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 3 In-Reply-To: References: Message-ID: <78F281B5-EC75-4510-B1C1-C11F0D63A5BE@mpi-sws.org> Hi Ricardo, > On 15. May 2019, at 02:44, Ricardo Teixeira wrote: > >> Below are the kernel messages for the overhead and schedule tracers. these messages look reasonable; I don’t see anything suggesting that there might be a problem. >> When I'm looking for UNLOCK events through ftdump, I noticed that almost all UNLOCK_START records are generated with IRQ enabled for both protocols I'm running. What do you mean with “almost all [...] with IRQ enabled”? Do you have different lock entry paths, some with IRQs enabled and some without? Or do you mean the IRQ field in the trace records? That’s a snapshot of the core’s IRQ *counter*, which is reset when it is read. It’s perfectly normal for this number to be non-zero for a _START event — on average, you’d expect there to have been some interrupts since the last time that an event was recorded. >> Is this why these records are not being counted? Is there any parameter so I can collect these records? Yes, -x disables interrupt filtering, but, again, this should not be an issue for _START events. https://github.com/LITMUS-RT/feather-trace-tools/blob/master/src/ft2csv.c#L397 You had mentioned in some email that you use “inherited” scripts that produce a single .ft file — I have no idea what these scripts are, where they come from, or what they do, so I can’t really help you debug them. I would recommend to use the standard tools as described in the tutorial. https://github.com/LITMUS-RT/feather-trace-tools/blob/master/doc/howto-trace-and-process-overheads.md At the very least, see if the problem persists if you follow that approach. Regards, Björn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2334 bytes Desc: not available URL: From ricardo.btxr at gmail.com Thu May 16 04:16:55 2019 From: ricardo.btxr at gmail.com (Ricardo Teixeira) Date: Wed, 15 May 2019 23:16:55 -0300 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 5 In-Reply-To: References: Message-ID: Hi Björn. I meant the IRQ field in the trace logs. 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? The protocol I am testing is not suspension-based, but it can call the litmus_reschedule() method at the end of unlock() plugin method. I'll try with the standard tools to get the records of the other processors, as you suggested. Thank you again. UNLOCK_START seq: 372140 pid: 5086 timestamp: 7003579867914 cpu: 0 type: RT irq: 1 irqc: 01 SCHED_START seq: 372141 pid: 5086 timestamp: 7003579871038 cpu: 0 type: UNKNOWN irq: 0 irqc: 00 SCHED_END seq: 372142 pid: 5086 timestamp: 7003579875406 cpu: 0 type: RT irq: 0 irqc: 00 SCHED2_START seq: 372143 pid: 5086 timestamp: 7003579875842 cpu: 0 type: RT irq: 0 irqc: 00 SCHED2_END seq: 372144 pid: 5086 timestamp: 7003579876844 cpu: 0 type: RT irq: 0 irqc: 00 UNLOCK_END seq: 372145 pid: 5086 timestamp: 7003579877156 cpu: 0 type: RT irq: 0 irqc: 00 Em qua, 15 de mai de 2019 às 07:00, 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: litmus-dev Digest, Vol 81, Issue 3 (Björn Brandenburg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 May 2019 09:30:12 +0200 > From: Björn Brandenburg > To: litmus-dev at lists.litmus-rt.org > Subject: Re: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 3 > Message-ID: <78F281B5-EC75-4510-B1C1-C11F0D63A5BE at mpi-sws.org> > Content-Type: text/plain; charset="utf-8" > > Hi Ricardo, > > > On 15. May 2019, at 02:44, Ricardo Teixeira > wrote: > > > >> Below are the kernel messages for the overhead and schedule tracers. > > these messages look reasonable; I don’t see anything suggesting that there > might be a problem. > > >> When I'm looking for UNLOCK events through ftdump, I noticed that > almost all UNLOCK_START records are generated with IRQ enabled for both > protocols I'm running. > > What do you mean with “almost all [...] with IRQ enabled”? Do you have > different lock entry paths, some with IRQs enabled and some without? > > Or do you mean the IRQ field in the trace records? That’s a snapshot of > the core’s IRQ *counter*, which is reset when it is read. It’s perfectly > normal for this number to be non-zero for a _START event — on average, > you’d expect there to have been some interrupts since the last time that an > event was recorded. > > >> Is this why these records are not being counted? Is there any parameter > so I can collect these records? > > Yes, -x disables interrupt filtering, but, again, this should not be an > issue for _START events. > > > https://github.com/LITMUS-RT/feather-trace-tools/blob/master/src/ft2csv.c#L397 > > You had mentioned in some email that you use “inherited” scripts that > produce a single .ft file — I have no idea what these scripts are, where > they come from, or what they do, so I can’t really help you debug them. I > would recommend to use the standard tools as described in the tutorial. > > > https://github.com/LITMUS-RT/feather-trace-tools/blob/master/doc/howto-trace-and-process-overheads.md > > At the very least, see if the problem persists if you follow that > approach. > > Regards, > Björn > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20190515/824b17dc/attachment-0001.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 2334 bytes > Desc: not available > URL: < > http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20190515/824b17dc/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 81, Issue 5 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.haibach at yahoo.de Thu May 16 11:32:12 2019 From: julien.haibach at yahoo.de (Julien Haibach) Date: Thu, 16 May 2019 09:32:12 +0000 (UTC) Subject: [LITMUS^RT] P-RES: waking up tasks before timeout References: <1159738664.634203.1557999132236.ref@mail.yahoo.com> Message-ID: <1159738664.634203.1557999132236@mail.yahoo.com> Hi, 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. Best Regards,Julien -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Thu May 16 12:17:41 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Thu, 16 May 2019 12:17:41 +0200 Subject: [LITMUS^RT] P-RES: waking up tasks before timeout In-Reply-To: <1159738664.634203.1557999132236@mail.yahoo.com> References: <1159738664.634203.1557999132236.ref@mail.yahoo.com> <1159738664.634203.1557999132236@mail.yahoo.com> Message-ID: <55682065-9CC1-4992-8D9D-B2E45966C0CD@mpi-sws.org> > On 16. May 2019, at 11:32, Julien Haibach 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: From bbb at mpi-sws.org Thu May 16 12:21:52 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Thu, 16 May 2019 12:21:52 +0200 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 5 In-Reply-To: References: Message-ID: <087E2F91-462C-460E-8165-EDECE0E6F4A0@mpi-sws.org> > On 16. May 2019, at 04:16, Ricardo Teixeira 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: From JorgeLuis.MartinezGarcia at de.bosch.com Thu May 16 22:45:23 2019 From: JorgeLuis.MartinezGarcia at de.bosch.com (Martinez Garcia Jorge Luis (PS-EC/ESB2)) Date: Thu, 16 May 2019 20:45:23 +0000 Subject: [LITMUS^RT] Overheads Message-ID: 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: From ricardo.btxr at gmail.com Fri May 17 04:24:00 2019 From: ricardo.btxr at gmail.com (Ricardo Teixeira) Date: Thu, 16 May 2019 23:24:00 -0300 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 7 In-Reply-To: References: Message-ID: 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, 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 > 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 > 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 > 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 > 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)" > > To: "litmus-dev at lists.litmus-rt.org" > Subject: [LITMUS^RT] Overheads > Message-ID: > 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: From bbb at mpi-sws.org Fri May 17 08:52:03 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Fri, 17 May 2019 08:52:03 +0200 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 7 In-Reply-To: References: Message-ID: <12B2773B-46CB-4422-8274-3ACFE7D8037A@mpi-sws.org> > On 17. May 2019, at 04:24, Ricardo Teixeira wrote: > > 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. Dear Ricardo, thanks for sharing your find. If you’d like to submit a patch that makes this behavior optional via a command-line argument, I’d be happy to merge it. 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: From bbb at mpi-sws.org Fri May 17 08:56:18 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Fri, 17 May 2019 08:56:18 +0200 Subject: [LITMUS^RT] Overheads In-Reply-To: References: Message-ID: <969E0BE6-490A-4FAE-87A8-DD40DB6FE491@mpi-sws.org> Hi Jorge, > On 16. May 2019, at 22:45, Martinez Garcia Jorge Luis (PS-EC/ESB2) wrote: > > 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) yes, this is correct. > and SCHED + SCHED2 for process selection (scheduling overhead). Correct. > 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)? Yes: RELEASE is the cost in cycles of processing the release event in interrupt context, and RELEASE-LATENCY is the delta (in IIRC nanoseconds) between when the release should have occurred (i.e., the time at which the timer was programmed to expire) and when it was actually processed. > What does SEND-RESCHED account for? The latency between when an IPI is sent and when it is processed by the remote core. > 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? There is no extra event for job completions; any cycles spent on calling into the kernel to indicate job completion are part of the job’s regular execution cost. Dispatching the next job are regular scheduling and context-switch events. 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: From sobhan.niknam at yahoo.com Fri May 17 15:27:19 2019 From: sobhan.niknam at yahoo.com (sobhan niknam) Date: Fri, 17 May 2019 15:27:19 +0200 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> References: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> Message-ID: Dear Bjorn, I installed LITMUS-RT on odroid xu4 that has ARM Cortex A15 and A7 CPU cores. When I run a multithreaded real-time application on LITMUS-RT, the trace file doesn’t look fine! Although the application seems to run correctly, there are some mess in the trace file, e.g., some parts of the trace file is empty. Can you please help me and tell me what can cause this problem? An example trace file is attached below. Best Regards, Sobhan Niknam > On 1 Feb 2019, at 14:44, Björn Brandenburg wrote: > > Dear Sobhan, > >> On 1. Feb 2019, at 14:38, sobhan niknam wrote: >> >> I followed this instruction step by step to install LITMUS RT on Ubuntu 14.04.1 LTS on Odroid XU4 platform. > > Those instructions assume an x86 platform. > >> However, my linux doesn’t have grub for configuring the boot loader. Instead, according to my search, the ARM-based embedded systems have u-boot. > > Indeed, that’s correct. > >> Can anybody tell me how I can configure the boot loader to show the LITMUS RT kernel in the boot menu? >> I look forward to hearing from you very soon. > > We don’t have ready-to-go instructions for configuring uboot (feel free to contribute a guide!), this often depends very much on your specific SoC and your distro / vendor config. In the past, I’ve had luck with setting up tftp boot. My suggestion would be to google for instructions for configuring the Odroid XU4 to boot via tftp. > > Regards, > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: schedule_host=odroid_scheduler=PSN-EDF_trace=.pdf Type: application/pdf Size: 152263 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Fri May 17 15:51:52 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Fri, 17 May 2019 15:51:52 +0200 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: References: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> Message-ID: On 17. May 2019, at 15:27, sobhan niknam wrote: > > > I installed LITMUS-RT on odroid xu4 that has ARM Cortex A15 and A7 CPU cores. When I run a multithreaded real-time application on LITMUS-RT, the trace file doesn’t look fine! Although the application seems to run correctly, there are some mess in the trace file, e.g., some parts of the trace file is empty. Can you please help me and tell me what can cause this problem? An example trace file is attached below. No, sorry, without further details there’s not much that I can say. As a starter, I would make sure that you are not missing any trace events due to trace buffer overflows. - Björn -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5061 bytes Desc: not available URL: From ricardo.btxr at gmail.com Sun May 19 22:52:12 2019 From: ricardo.btxr at gmail.com (Ricardo Teixeira) Date: Sun, 19 May 2019 17:52:12 -0300 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 11 In-Reply-To: References: Message-ID: Hi, Does anyone know if the difference between these parameters can influence the overhead times? 396a397 > CONFIG_MUTEX_SPIN_ON_OWNER=y 601c602 < # CONFIG_HZ_250 is not set --- > CONFIG_HZ_250=y 603,604c604,605 < CONFIG_HZ_1000=y < CONFIG_HZ=1000 --- > # CONFIG_HZ_1000 is not set > CONFIG_HZ=250 8208,8211c8209,8212 < CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y < CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1 < CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y < CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 --- > # CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set > CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0 > # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set > CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 8214,8215c8215,8216 < CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y < CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1 --- > # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set > CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 8231,8233c8232,8234 < CONFIG_DEBUG_RT_MUTEXES=y < CONFIG_DEBUG_SPINLOCK=y < CONFIG_DEBUG_MUTEXES=y --- > # CONFIG_DEBUG_RT_MUTEXES is not set > # CONFIG_DEBUG_SPINLOCK is not set > # CONFIG_DEBUG_MUTEXES is not set 8235c8236 < CONFIG_DEBUG_LOCK_ALLOC=y --- > # CONFIG_DEBUG_LOCK_ALLOC is not set 8237d8237 < CONFIG_LOCKDEP=y 8239,8240c8239 < # CONFIG_DEBUG_LOCKDEP is not set < CONFIG_DEBUG_ATOMIC_SLEEP=y --- > # CONFIG_DEBUG_ATOMIC_SLEEP is not set 8843c8842 < CONFIG_SCHED_TASK_TRACE_SHIFT=12 --- > CONFIG_SCHED_TASK_TRACE_SHIFT=9 8846c8845 < CONFIG_SCHED_OVERHEAD_TRACE_SHIFT=26 --- > CONFIG_SCHED_OVERHEAD_TRACE_SHIFT=22 8848c8847 < CONFIG_SCHED_DEBUG_TRACE_SHIFT=22 --- > CONFIG_SCHED_DEBUG_TRACE_SHIFT=18 Best regards, Ricardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricardo.btxr at gmail.com Sun May 19 22:57:21 2019 From: ricardo.btxr at gmail.com (Ricardo Teixeira) Date: Sun, 19 May 2019 17:57:21 -0300 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 8 In-Reply-To: References: Message-ID: Hi Björn, I'd like to send these changes made to the ft2csv code, but I'm not sure about the impacts on the suspension-based protocols. I have not tested these protocols. Best regards, Ricardo Em sex, 17 de mai de 2019 às 03:53, 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: litmus-dev Digest, Vol 81, Issue 7 (Ricardo Teixeira) > 2. Re: litmus-dev Digest, Vol 81, Issue 7 (Björn Brandenburg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 May 2019 23:24:00 -0300 > From: Ricardo Teixeira > To: litmus-dev at lists.litmus-rt.org > Subject: Re: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 7 > Message-ID: > < > CADjj2cGtt9aGviCPZPpbdO0a957+xvMz74bEubVXbLK+2usVig at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > > 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 > > 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 > > 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 > > 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)" > > > > To: "litmus-dev at lists.litmus-rt.org" > > Subject: [LITMUS^RT] Overheads > > Message-ID: > > 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-0001.html > > > > ------------------------------ > > Message: 2 > Date: Fri, 17 May 2019 08:52:03 +0200 > From: Björn Brandenburg > To: litmus-dev at lists.litmus-rt.org > Subject: Re: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 7 > Message-ID: <12B2773B-46CB-4422-8274-3ACFE7D8037A at mpi-sws.org> > Content-Type: text/plain; charset="utf-8" > > > > > On 17. May 2019, at 04:24, Ricardo Teixeira > wrote: > > > > 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. > > Dear Ricardo, > > thanks for sharing your find. If you’d like to submit a patch that makes > this behavior optional via a command-line argument, I’d be happy to merge > it. > > 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/20190517/6cc14ff3/attachment.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 81, Issue 8 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Mon May 20 13:08:51 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Mon, 20 May 2019 13:08:51 +0200 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 11 In-Reply-To: References: Message-ID: <5CD5F2DE-0040-49B0-9CC2-5075B9FC0339@mpi-sws.org> > On 19. May 2019, at 22:52, Ricardo Teixeira wrote: > Does anyone know if the difference between these parameters can influence the overhead times? > […] > > # CONFIG_DEBUG_RT_MUTEXES is not set > > # CONFIG_DEBUG_SPINLOCK is not set > > # CONFIG_DEBUG_MUTEXES is not set > 8235c8236 > < CONFIG_DEBUG_LOCK_ALLOC=y > --- > > # CONFIG_DEBUG_LOCK_ALLOC is not set > 8237d8237 > < CONFIG_LOCKDEP=y > 8239,8240c8239 > < # CONFIG_DEBUG_LOCKDEP is not set > < CONFIG_DEBUG_ATOMIC_SLEEP=y > --- > > # CONFIG_DEBUG_ATOMIC_SLEEP is not set Hi Ricardo, lockdep and related lock-debugging options can be very expensive in terms of overheads. - Björn -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5061 bytes Desc: not available URL: From bbb at mpi-sws.org Mon May 20 13:10:16 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Mon, 20 May 2019 13:10:16 +0200 Subject: [LITMUS^RT] litmus-dev Digest, Vol 81, Issue 8 In-Reply-To: References: Message-ID: <9627FFC8-B933-47FF-9618-78DCE41FA7CE@mpi-sws.org> > On 19. May 2019, at 22:57, Ricardo Teixeira wrote: > > > I'd like to send these changes made to the ft2csv code, but I'm not sure about the impacts on the suspension-based protocols. I have not tested these protocols. Just don’t change the existing behavior, so I’d suggest to make it an option that is disabled by default. - Björn -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5061 bytes Desc: not available URL: From sobhan.niknam at yahoo.com Mon May 20 15:55:25 2019 From: sobhan.niknam at yahoo.com (sobhan niknam) Date: Mon, 20 May 2019 15:55:25 +0200 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: <3867773E-92A5-41F1-9130-4CF1516A4139@yahoo.com> References: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> <1898F2AC-BBEF-471B-B3D5-3D397BABF7AB@yahoo.com> <3867773E-92A5-41F1-9130-4CF1516A4139@yahoo.com> Message-ID: <681E9925-B1C7-4BD1-AD10-F9C87D8F8A54@yahoo.com> Dear Bjorn, Can you please tell me where I should look at? or which further details you require to help me? I look forward to hearing from you. Best Regards, Sobhan Niknam > > >> On 17 May 2019, at 16:07, sobhan niknam > wrote: >> >> >> Thank you so much for your fast reply. >> >>> On 17 May 2019, at 15:51, Björn Brandenburg > wrote: >>> >>> On 17. May 2019, at 15:27, sobhan niknam > wrote: >>>> >>>> >>>> I installed LITMUS-RT on odroid xu4 that has ARM Cortex A15 and A7 CPU cores. When I run a multithreaded real-time application on LITMUS-RT, the trace file doesn’t look fine! Although the application seems to run correctly, there are some mess in the trace file, e.g., some parts of the trace file is empty. Can you please help me and tell me what can cause this problem? An example trace file is attached below. >>> >>> No, sorry, without further details there’s not much that I can say. >>> As a starter, I would make sure that you are not missing any trace events due to trace buffer overflows. >> >> Ok, how can I check if the buffers are not overloaded? >> >> Best Regards, >> Sobhan >> >>> - Björn >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Mon May 20 16:01:58 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Mon, 20 May 2019 16:01:58 +0200 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: <681E9925-B1C7-4BD1-AD10-F9C87D8F8A54@yahoo.com> References: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> <1898F2AC-BBEF-471B-B3D5-3D397BABF7AB@yahoo.com> <3867773E-92A5-41F1-9130-4CF1516A4139@yahoo.com> <681E9925-B1C7-4BD1-AD10-F9C87D8F8A54@yahoo.com> Message-ID: <252C3CBA-994C-47F6-ABF6-29E375295299@mpi-sws.org> > On 20. May 2019, at 15:55, sobhan niknam wrote: > > Can you please tell me where I should look at? The kernel’s message log should contain a line such as the following for each core. Failed trace writes: 0 If the number is different from 0, the trace buffers overflowed. - Björn From sobhan.niknam at yahoo.com Mon May 20 16:40:39 2019 From: sobhan.niknam at yahoo.com (sobhan niknam) Date: Mon, 20 May 2019 16:40:39 +0200 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: <252C3CBA-994C-47F6-ABF6-29E375295299@mpi-sws.org> References: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> <1898F2AC-BBEF-471B-B3D5-3D397BABF7AB@yahoo.com> <3867773E-92A5-41F1-9130-4CF1516A4139@yahoo.com> <681E9925-B1C7-4BD1-AD10-F9C87D8F8A54@yahoo.com> <252C3CBA-994C-47F6-ABF6-29E375295299@mpi-sws.org> Message-ID: <64990A40-121C-41A5-A791-D0ADA7C5BCFA@yahoo.com> > On 20 May 2019, at 16:01, Björn Brandenburg wrote: > > > >> On 20. May 2019, at 15:55, sobhan niknam wrote: >> >> Can you please tell me where I should look at? > > The kernel’s message log should contain a line such as the following for each core. > > Failed trace writes: 0 > There is no log file in /dev/litmus to look at. However, what should I do if supposing the trace buffers overflowed? Best regards, Sobhan > If the number is different from 0, the trace buffers overflowed. > > - Björn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Mon May 20 17:40:07 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Mon, 20 May 2019 17:40:07 +0200 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: <64990A40-121C-41A5-A791-D0ADA7C5BCFA@yahoo.com> References: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> <1898F2AC-BBEF-471B-B3D5-3D397BABF7AB@yahoo.com> <3867773E-92A5-41F1-9130-4CF1516A4139@yahoo.com> <681E9925-B1C7-4BD1-AD10-F9C87D8F8A54@yahoo.com> <252C3CBA-994C-47F6-ABF6-29E375295299@mpi-sws.org> <64990A40-121C-41A5-A791-D0ADA7C5BCFA@yahoo.com> Message-ID: <227BA43C-77D2-46A7-A7D8-4B97A96DD514@mpi-sws.org> On 20. May 2019, at 16:40, sobhan niknam wrote: > > There is no log file in /dev/litmus to look at. I’m not talking about a LITMUS^RT-specific device file. Check the standard kernel log. > However, what should I do if supposing the trace buffers overflowed? If you have enough memory, increase the trace buffer size. Otherwise, make sure they get drained quickly enough. - Björn -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2334 bytes Desc: not available URL: From sobhan.niknam at yahoo.com Mon May 20 18:35:35 2019 From: sobhan.niknam at yahoo.com (sobhan niknam) Date: Mon, 20 May 2019 18:35:35 +0200 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: <227BA43C-77D2-46A7-A7D8-4B97A96DD514@mpi-sws.org> References: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> <1898F2AC-BBEF-471B-B3D5-3D397BABF7AB@yahoo.com> <3867773E-92A5-41F1-9130-4CF1516A4139@yahoo.com> <681E9925-B1C7-4BD1-AD10-F9C87D8F8A54@yahoo.com> <252C3CBA-994C-47F6-ABF6-29E375295299@mpi-sws.org> <64990A40-121C-41A5-A791-D0ADA7C5BCFA@yahoo.com> <227BA43C-77D2-46A7-A7D8-4B97A96DD514@mpi-sws.org> Message-ID: <68A5E4CB-7B5B-455A-AD20-17955682F0DF@yahoo.com> > On 20 May 2019, at 17:40, Björn Brandenburg wrote: > > On 20. May 2019, at 16:40, sobhan niknam wrote: >> >> There is no log file in /dev/litmus to look at. > > I’m not talking about a LITMUS^RT-specific device file. Check the standard kernel log. The buffers overflowed: May 21 01:12:37 odroid kernel: [341828.508325] [c1] Failed trace writes: 25486 May 21 01:12:37 odroid kernel: [341828.508344] [c3] Failed trace writes: 46617 May 21 01:12:37 odroid kernel: [341828.508364] [c0] Failed trace writes: 19335 May 21 01:12:37 odroid kernel: [341828.508381] [c2] Failed trace writes: 0 May 21 01:12:37 odroid kernel: [341828.508619] [c2] Failed trace writes: 6915121 May 21 01:12:37 odroid kernel: [341828.508627] [c0] Failed trace writes: 6713421 May 21 01:12:37 odroid kernel: [341828.508696] [c3] Failed trace writes: 23201 May 21 01:12:37 odroid kernel: [341828.511328] [c3] Failed trace writes: 7169319 >> However, what should I do if supposing the trace buffers overflowed? > > If you have enough memory, increase the trace buffer size. Otherwise, make sure they get drained quickly enough. I increased the buffer size of each cpu core in /sys/kernel/debug/buffer_size_kb, but the problem still exists! Sobhan > - Björn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Tue May 21 17:44:29 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Tue, 21 May 2019 17:44:29 +0200 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: <68A5E4CB-7B5B-455A-AD20-17955682F0DF@yahoo.com> References: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> <1898F2AC-BBEF-471B-B3D5-3D397BABF7AB@yahoo.com> <3867773E-92A5-41F1-9130-4CF1516A4139@yahoo.com> <681E9925-B1C7-4BD1-AD10-F9C87D8F8A54@yahoo.com> <252C3CBA-994C-47F6-ABF6-29E375295299@mpi-sws.org> <64990A40-121C-41A5-A791-D0ADA7C5BCFA@yahoo.com> <227BA43C-77D2-46A7-A7D8-4B97A96DD514@mpi-sws.org> <68A5E4CB-7B5B-455A-AD20-17955682F0DF@yahoo.com> Message-ID: > On 20. May 2019, at 18:35, sobhan niknam wrote: > > > >> On 20 May 2019, at 17:40, Björn Brandenburg wrote: >> >> On 20. May 2019, at 16:40, sobhan niknam wrote: >>> >>> There is no log file in /dev/litmus to look at. >> >> I’m not talking about a LITMUS^RT-specific device file. Check the standard kernel log. > > The buffers overflowed: > > May 21 01:12:37 odroid kernel: [341828.508325] [c1] Failed trace writes: 25486 > May 21 01:12:37 odroid kernel: [341828.508344] [c3] Failed trace writes: 46617 > May 21 01:12:37 odroid kernel: [341828.508364] [c0] Failed trace writes: 19335 > May 21 01:12:37 odroid kernel: [341828.508381] [c2] Failed trace writes: 0 > May 21 01:12:37 odroid kernel: [341828.508619] [c2] Failed trace writes: 6915121 > May 21 01:12:37 odroid kernel: [341828.508627] [c0] Failed trace writes: 6713421 > May 21 01:12:37 odroid kernel: [341828.508696] [c3] Failed trace writes: 23201 > May 21 01:12:37 odroid kernel: [341828.511328] [c3] Failed trace writes: 7169319 Makes sense. If you have gaps in the record, then of course the resulting traces will be incomplete and/or strange. > >>> However, what should I do if supposing the trace buffers overflowed? >> >> If you have enough memory, increase the trace buffer size. Otherwise, make sure they get drained quickly enough. > > > I increased the buffer size of each cpu core in /sys/kernel/debug/buffer_size_kb, but the problem still exists! I’m not sure how you hit on that setting, but I don’t think it has anything to do with LITMUS^RT. The LITMUS^RT trace buffers are configured statically via .config. - Björn From gelliott at cs.unc.edu Tue May 21 18:23:27 2019 From: gelliott at cs.unc.edu (Glenn Elliott) Date: Tue, 21 May 2019 09:23:27 -0700 Subject: [LITMUS^RT] Installing LITMUS RT on Odroid XU4 In-Reply-To: References: <6CAC8CFE-A4A6-4BEB-B478-2C519BA4638D@mpi-sws.org> <1898F2AC-BBEF-471B-B3D5-3D397BABF7AB@yahoo.com> <3867773E-92A5-41F1-9130-4CF1516A4139@yahoo.com> <681E9925-B1C7-4BD1-AD10-F9C87D8F8A54@yahoo.com> <252C3CBA-994C-47F6-ABF6-29E375295299@mpi-sws.org> <64990A40-121C-41A5-A791-D0ADA7C5BCFA@yahoo.com> <227BA43C-77D2-46A7-A7D8-4B97A96DD514@mpi-sws.org> <68A5E4CB-7B5B-455A-AD20-17955682F0DF@yahoo.com> Message-ID: >> I increased the buffer size of each cpu core in /sys/kernel/debug/buffer_size_kb, but the problem still exists! > I’m not sure how you hit on that setting, but I don’t think it has anything to do with LITMUS^RT. The LITMUS^RT trace buffers are configured statically via .config. To clarify: "/sys/kernel/debug/tracing/buffer_size_kb" is an ftrace configuration parameter ( https://www.kernel.org/doc/Documentation/trace/ftrace.txt). Linux's ftrace is distinct from Litmus's "feather trace." The size of feather trace buffers is controlled by the .config parameter CONFIG_SCHED_TASK_TRACE_SHIFT (see litmus/Kconfig). -Glenn On Tue, May 21, 2019 at 8:45 AM Björn Brandenburg wrote: > > > > On 20. May 2019, at 18:35, sobhan niknam > wrote: > > > > > > > >> On 20 May 2019, at 17:40, Björn Brandenburg wrote: > >> > >> On 20. May 2019, at 16:40, sobhan niknam > wrote: > >>> > >>> There is no log file in /dev/litmus to look at. > >> > >> I’m not talking about a LITMUS^RT-specific device file. Check the > standard kernel log. > > > > The buffers overflowed: > > > > May 21 01:12:37 odroid kernel: [341828.508325] [c1] Failed trace writes: > 25486 > > May 21 01:12:37 odroid kernel: [341828.508344] [c3] Failed trace writes: > 46617 > > May 21 01:12:37 odroid kernel: [341828.508364] [c0] Failed trace writes: > 19335 > > May 21 01:12:37 odroid kernel: [341828.508381] [c2] Failed trace writes: > 0 > > May 21 01:12:37 odroid kernel: [341828.508619] [c2] Failed trace writes: > 6915121 > > May 21 01:12:37 odroid kernel: [341828.508627] [c0] Failed trace writes: > 6713421 > > May 21 01:12:37 odroid kernel: [341828.508696] [c3] Failed trace writes: > 23201 > > May 21 01:12:37 odroid kernel: [341828.511328] [c3] Failed trace writes: > 7169319 > > Makes sense. If you have gaps in the record, then of course the resulting > traces will be incomplete and/or strange. > > > > >>> However, what should I do if supposing the trace buffers overflowed? > >> > >> If you have enough memory, increase the trace buffer size. Otherwise, > make sure they get drained quickly enough. > > > > > > I increased the buffer size of each cpu core in > /sys/kernel/debug/buffer_size_kb, but the problem still exists! > > I’m not sure how you hit on that setting, but I don’t think it has > anything to do with LITMUS^RT. The LITMUS^RT trace buffers are configured > statically via .config. > > - 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: From sobhan.niknam at yahoo.com Wed May 29 12:28:43 2019 From: sobhan.niknam at yahoo.com (sobhan niknam) Date: Wed, 29 May 2019 12:28:43 +0200 Subject: [LITMUS^RT] LITMUS RT on Odroid Xu4 platform Message-ID: Dear Björn, I have encountered with a transient problem when I run an application with parallel real-time tasks using pthreads. Sometimes the tasks’ job are not released in correct time. You can see the problem in figure below, the second job of the last task is released at 13ms instead of 10ms! Do you have any idea where this problem comes from? Best Regards, Sobhan Niknam ———————————————————————— Sobhan Niknam PhD student, Leiden Embedded Research Center (LERC), Leiden Institute of Advanced Computer Science (LIACS), Leiden University -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: schedule_host=odroid_scheduler=PSN-EDF_trace=2.pdf Type: application/pdf Size: 22580 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Wed May 29 14:08:47 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Wed, 29 May 2019 14:08:47 +0200 Subject: [LITMUS^RT] LITMUS RT on Odroid Xu4 platform In-Reply-To: References: Message-ID: <1806C03A-791D-4F2D-BF11-14F7D65852A8@mpi-sws.org> > On 29. May 2019, at 12:28, sobhan niknam wrote: > > I have encountered with a transient problem when I run an application with parallel real-time tasks using pthreads. Sometimes the tasks’ job are not released in correct time. You can see the problem in figure below, the second job of the last task is released at 13ms instead of 10ms! > Do you have any idea where this problem comes from? Hi Sobhan, no, sorry, I don’t. And how should I? I don’t know which plugin you are using, I don’t know your application, I don’t know what code you are running, I don’t which facilities you are using to create your real-time threads and control their timing, etc. From just one figure, it’s really hard to guess as to what might be going on. Just looking at your figure, though, one can see that mjpeg/32084 self-suspends shortly after its first release, and that it doesn’t resume until shortly before time 13. LITMUS^RT interprets a thread’s self-suspension that exceeds past the thread’s current deadline/next-earliest-release time as a new job release. Put differently, why would you expect a job release to occur while the thread is not runnable? If you want that behavior, you need to use periodic polling reservations in the P-RES plugin. - Björn -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5061 bytes Desc: not available URL: From sobhan.niknam at yahoo.com Wed May 29 18:00:08 2019 From: sobhan.niknam at yahoo.com (sobhan niknam) Date: Wed, 29 May 2019 18:00:08 +0200 Subject: [LITMUS^RT] LITMUS RT on Odroid Xu4 platform In-Reply-To: <1806C03A-791D-4F2D-BF11-14F7D65852A8@mpi-sws.org> References: <1806C03A-791D-4F2D-BF11-14F7D65852A8@mpi-sws.org> Message-ID: <29A76D62-2B3B-4804-9ECD-F6D35B659DD8@yahoo.com> > On 29 May 2019, at 14:08, Björn Brandenburg wrote: > > > >> On 29. May 2019, at 12:28, sobhan niknam wrote: >> >> I have encountered with a transient problem when I run an application with parallel real-time tasks using pthreads. Sometimes the tasks’ job are not released in correct time. You can see the problem in figure below, the second job of the last task is released at 13ms instead of 10ms! >> Do you have any idea where this problem comes from? > > Hi Sobhan, > > no, sorry, I don’t. And how should I? I don’t know which plugin you are using, I am using PSN-EDF > I don’t know your application, I don’t know what code you are running, My application is mjpeg that has 6 parallel tasks implemented with pthreads with similar structure as base_mt_task.c > I don’t which facilities you are using to create your real-time threads and control their timing, etc. From just one figure, it’s really hard to guess as to what might be going on. > > Just looking at your figure, though, one can see that mjpeg/32084 self-suspends shortly after its first release, and that it doesn’t resume until shortly before time 13. LITMUS^RT interprets a thread’s self-suspension that exceeds past the thread’s current deadline/next-earliest-release time as a new job release. Put differently, why would you expect a job release to occur while the thread is not runnable? If you want that behavior, you need to use periodic polling reservations in the P-RES plugin. I exactly used the same structure as base_mt_task.c to create the threads, setup tasks parameters (real-time periodic tasks), and invoke real-time jobs of the threads for mjpeg application. However, this implementation sometimes works successfully and sometimes fails due to self-suspention, I don’t know why, and the tasks’ job are not released at correct expected moments! Best Regards, Sobhan > > - Björn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.niknam at liacs.leidenuniv.nl Thu Jul 4 13:42:22 2019 From: s.niknam at liacs.leidenuniv.nl (niknams) Date: Thu, 4 Jul 2019 13:42:22 +0200 Subject: [LITMUS^RT] =?utf-8?q?=28no_subject=29?= Message-ID: <8A14F51A-F8EB-478B-A472-E8808529B640@liacs.leidenuniv.nl> Dear All, Regarding reservation-based scheduling plugin (P-RES) in LITMUS RT, I want to execute tasks with precedence constraints that are mapped on different processors according to a derived static schedule. But, I was wondering, is it possible to define synchronised table-driven reservations on different processors? I look forward to hearing from you. Best Regards, Sobhan Niknam -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Fri Jul 5 09:29:19 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Fri, 5 Jul 2019 09:29:19 +0200 Subject: [LITMUS^RT] (no subject) In-Reply-To: <8A14F51A-F8EB-478B-A472-E8808529B640@liacs.leidenuniv.nl> References: <8A14F51A-F8EB-478B-A472-E8808529B640@liacs.leidenuniv.nl> Message-ID: On 4. Jul 2019, at 13:42, niknams wrote: > > Regarding reservation-based scheduling plugin (P-RES) in LITMUS RT, I want to execute tasks with precedence constraints that are mapped on different processors according to a derived static schedule. But, I was wondering, is it possible to define synchronised table-driven reservations on different processors? > I look forward to hearing from you. Yes, that is trivially possible. All tables follow the same timeline (CLOCK_MONOTONIC). - Björn From filip.markovic at mdh.se Thu Aug 15 14:23:07 2019 From: filip.markovic at mdh.se (Filip Markovic) Date: Thu, 15 Aug 2019 12:23:07 +0000 Subject: [LITMUS^RT] Instructions for installing Litmus-RT on Raspbian OS Message-ID: Dear litmus users and researchers, In the attachment, you may find the installation instructions for Litmus-RT on Raspbian OS. I saw that several tries before were not successful and that there is no information on this topic available online. Thank you all for this amazing kernel extension and set of tools! Kind regards, Filip Markovic -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Installing LITMUS-RT on Raspbian OS.pdf Type: application/pdf Size: 175370 bytes Desc: Installing LITMUS-RT on Raspbian OS.pdf URL: From bbb at mpi-sws.org Thu Aug 15 14:48:23 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Thu, 15 Aug 2019 14:48:23 +0200 Subject: [LITMUS^RT] Instructions for installing Litmus-RT on Raspbian OS In-Reply-To: References: Message-ID: <045C0294-DF68-4BD6-90E1-3FAE2E4DD5BD@mpi-sws.org> > On 15. Aug 2019, at 14:23, Filip Markovic wrote: > > In the attachment, you may find the installation instructions for Litmus-RT on Raspbian OS. I saw that several tries before were not successful and that there is no information on this topic available online. Dear Filip, thanks a lot for contribution this very nice guide! I’ve added it to the LITMUS^RT documentation page (third item). http://www.litmus-rt.org/documentation.html Thanks, Björn -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5061 bytes Desc: not available URL: From sasnams.mec at gmail.com Fri Aug 30 11:38:24 2019 From: sasnams.mec at gmail.com (sasna ms) Date: Fri, 30 Aug 2019 15:08:24 +0530 Subject: [LITMUS^RT] how to run available schedulers Message-ID: i have got doubt in how to run available scheduler plugins in litmus-rt -------------- next part -------------- An HTML attachment was scrubbed... URL: From sasnams.mec at gmail.com Fri Aug 30 11:52:03 2019 From: sasnams.mec at gmail.com (sasna ms) Date: Fri, 30 Aug 2019 15:22:03 +0530 Subject: [LITMUS^RT] problem downloading litmus-rt Message-ID: i met with an error while downloading litmus-rt..someone please do help me out -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.PNG Type: image/png Size: 77964 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.PNG Type: image/png Size: 11066 bytes Desc: not available URL: From bbb at mpi-sws.org Fri Aug 30 12:16:41 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Fri, 30 Aug 2019 12:16:41 +0200 Subject: [LITMUS^RT] problem downloading litmus-rt In-Reply-To: References: Message-ID: On 30. Aug 2019, at 11:52, sasna ms wrote: > > i met with an error while downloading litmus-rt..someone please do help me out I cannot confirm; the link works for me. Does anyone else have problems downloading the VM image? - Björn From yorickdebock4 at gmail.com Fri Aug 30 12:39:44 2019 From: yorickdebock4 at gmail.com (Yorick De Bock) Date: Fri, 30 Aug 2019 12:39:44 +0200 Subject: [LITMUS^RT] problem downloading litmus-rt In-Reply-To: References: Message-ID: The link to the VM on this page works (https://www.litmus-rt.org/tutorial/index.html ) On this page (https://www.litmus-rt.org/tutorial/vm-setup.html ) the link doesn’t work for me, but I assume it is the same image as in the link above? Yorick > On 30 Aug 2019, at 12:16, Björn Brandenburg wrote: > > On 30. Aug 2019, at 11:52, sasna ms wrote: >> >> i met with an error while downloading litmus-rt..someone please do help me out > > I cannot confirm; the link works for me. Does anyone else have problems downloading the VM image? > > - 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: From bbb at mpi-sws.org Fri Aug 30 13:38:45 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Fri, 30 Aug 2019 13:38:45 +0200 Subject: [LITMUS^RT] problem downloading litmus-rt In-Reply-To: References: Message-ID: <7ADFA48D-9190-4F10-A06E-217AF4B21D32@mpi-sws.org> > On 30. Aug 2019, at 12:39, Yorick De Bock wrote: > > The link to the VM on this page works (https://www.litmus-rt.org/tutorial/index.html) > > On this page (https://www.litmus-rt.org/tutorial/vm-setup.html) the link doesn’t work for me, but I assume it is the same image as in the link above? Ah, I see, thanks for pointing this out. I’ve updated the link on the vm-setup.html page. For the record, if anyone would like to change/fix/improve anything on the web page, just submit a pull request to the LITMUS^RT homepage repo (https://github.com/litMUS-RT/www.litmus-rt.org). Thanks, Björn From sasnams.mec at gmail.com Wed Oct 23 09:24:25 2019 From: sasnams.mec at gmail.com (sasna ms) Date: Wed, 23 Oct 2019 12:54:25 +0530 Subject: [LITMUS^RT] =?utf-8?q?=28no_subject=29?= Message-ID: how to run an existing scheduler in litmus-rt -------------- next part -------------- An HTML attachment was scrubbed... URL: From sasnams.mec at gmail.com Thu Oct 24 11:14:53 2019 From: sasnams.mec at gmail.com (sasna ms) Date: Thu, 24 Oct 2019 14:44:53 +0530 Subject: [LITMUS^RT] modifying GSN-EDF Message-ID: i am currently trying to modify GSN-EDF scheduler.I would like to arrange the processes in the queue according to a criteria. ie, processes need to be selected according to a criteria and should be placed in the queue. Whether this idea work?Please give an advice Regards sasna.M.S -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Thu Oct 24 12:11:21 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Thu, 24 Oct 2019 12:11:21 +0200 Subject: [LITMUS^RT] modifying GSN-EDF In-Reply-To: References: Message-ID: > On 24. Oct 2019, at 11:14, sasna ms wrote: > > i am currently trying to modify GSN-EDF scheduler.I would like to arrange the processes in the queue according to a criteria. ie, processes need to be selected according to a criteria and should be placed in the queue. Whether this idea work?Please give an advice > Dear Sasna, there is no good way to answer such an open-ended question. I suggest you look through the archive of this mailing list to understand what kind of questions elicit a useful response. Please also note that this mailing list is specifically for technical discussions of LITMUS^RT; not general project management and research direction advice. Regards, Björn From sasnams.mec at gmail.com Thu Oct 24 15:55:13 2019 From: sasnams.mec at gmail.com (sasna ms) Date: Thu, 24 Oct 2019 19:25:13 +0530 Subject: [LITMUS^RT] =?utf-8?q?=28no_subject=29?= Message-ID: Respected sir, I am really sorry for the trouble.Was really confused about how am going to work this out.Hope your support will be there. Regards Sasna.M.S -------------- next part -------------- An HTML attachment was scrubbed... URL: From sasnams.mec at gmail.com Fri Oct 25 08:04:28 2019 From: sasnams.mec at gmail.com (sasna ms) Date: Fri, 25 Oct 2019 11:34:28 +0530 Subject: [LITMUS^RT] Fwd: In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: sasna ms Date: Fri, Oct 25, 2019 at 10:49 AM Subject: To: Respected sir, I have followed the steps in the tutorial slides (litmusrt-hands on primer) for visualising schedules with st-draw.The command "st-draw *.bin" worked fine but when i had executed "evince *.pdf" it is showing the following error "**(evince:2856):CRITICAL **:ev_bookmarks_get_bookmarks:assertion 'EV_IS_BOOKMARKS(bookmarks)'failed" Please help me out in solving this error. Regards SASNA.M.S -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbb at mpi-sws.org Fri Oct 25 10:41:43 2019 From: bbb at mpi-sws.org (=?utf-8?Q?Bj=C3=B6rn_Brandenburg?=) Date: Fri, 25 Oct 2019 10:41:43 +0200 Subject: [LITMUS^RT] Fwd: In-Reply-To: References: Message-ID: <37224B82-575F-4C16-B219-CC0F69691226@mpi-sws.org> On 25. Oct 2019, at 08:04, sasna ms wrote: > From: sasna ms > Date: Fri, Oct 25, 2019 at 10:49 AM > Subject: > To: > > > Respected sir, > I have followed the steps in the tutorial slides (litmusrt-hands on primer) for visualising schedules with st-draw.The command "st-draw *.bin" worked fine but when i had executed "evince *.pdf" it is showing the following error > > "**(evince:2856):CRITICAL **:ev_bookmarks_get_bookmarks:assertion 'EV_IS_BOOKMARKS(bookmarks)'failed" > > Please help me out in solving this error. As the message indicates, this is a report by “evince”, the PDF reader application. This has nothing to do with LITMUS^RT. - Björn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2334 bytes Desc: not available URL: From sasnams.mec at gmail.com Mon Oct 28 05:50:20 2019 From: sasnams.mec at gmail.com (sasna ms) Date: Mon, 28 Oct 2019 10:20:20 +0530 Subject: [LITMUS^RT] IPC, latest kernel Message-ID: Respected sir, I have got 2 queries regarding LITMUS-RT. 1)Is there any way to find the instruction per cycle of each and every process or thread? 2)Which is the latest kernel available in LITMUS-RT? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sasnams.mec at gmail.com Thu Oct 31 06:10:04 2019 From: sasnams.mec at gmail.com (sasna ms) Date: Thu, 31 Oct 2019 10:40:04 +0530 Subject: [LITMUS^RT] Bandwidth utilisation Message-ID: Respected sir, Is there any way to find the bandwidth utilisation of previously executed processes during last quantum? Please do help me out. Regards Sasna.M.S -------------- next part -------------- An HTML attachment was scrubbed... URL: From sasnams.mec at gmail.com Tue Nov 26 10:11:42 2019 From: sasnams.mec at gmail.com (sasna ms) Date: Tue, 26 Nov 2019 14:41:42 +0530 Subject: [LITMUS^RT] =?utf-8?q?=28no_subject=29?= Message-ID: Respected sir, I am trying to write a LITMUS-RT scheduler plugin. I had added sched_demo.o to the obj -y list in the litmus directory’s Makefile., But I coudn’t save it. Since it is saying that it is read only. How could I save it? [cornet at localhost ~]$ uname -a Linux localhost.localdomain 4.9.30Litmus-version+ #17 SMP PREEMPT Tue Mar 27 10:10:05 IST 2018 x86_64 x86_64 x86_64 GNU/Linux I also have another question: How to re-compile and re-install the kernel? I am stuck. Please do help me. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 92972 bytes Desc: not available URL: From hangsu.cs at gmail.com Tue Nov 26 10:12:09 2019 From: hangsu.cs at gmail.com (Hang Su) Date: Tue, 26 Nov 2019 01:12:09 -0800 Subject: [LITMUS^RT] (no subject) In-Reply-To: References: Message-ID: Hi SAS, Please stop spamming the channel. The questions you asked can be easily answered by google.com . Thanks. > On Nov 26, 2019, at 1:11 AM, sasna ms wrote: > > Respected sir, > I am trying to write a LITMUS-RT scheduler plugin. I had added sched_demo.o to the obj -y list in the litmus directory’s Makefile., But I coudn’t save it. Since it is saying that it is read only. How could I save it? > > [cornet at localhost ~]$ uname -a > Linux localhost.localdomain 4.9.30Litmus-version+ #17 SMP PREEMPT Tue Mar 27 10:10:05 IST 2018 x86_64 x86_64 x86_64 GNU/Linux > > I also have another question: How to re-compile and re-install the kernel? > I am stuck. Please do help me. > > Regards, > > > > <1.png>_______________________________________________ > 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: