<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hello Mathieu, Norbert and Jan,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thank you for all of your explainations and the overview of the system.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
No I didn't change the ipipe patch for the vDSO, I may try this.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
If I have correctly understood, this patch prevents Cobalt from entering in a deadlock when the kernel is using the vDSO and the program interrupts the kernel at the same time. On which kernel does it word (aroubd 4.19) ?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I currently try to avoid kernel 5.4 because I remember I faced some boot issues (but it is on another topic).</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Here the issues i faced (drawn on TraceCompass). Are these the deadlocks we are talking about ?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<a href="https://postimg.cc/BP4G3bF0" id="LPlnk">https://postimg.cc/BP4G3bF0</a> (on 11:02:56:380)</div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview_1 _EReadonly_1"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<a href="https://postimg.cc/q6wHvrcC" id="LPlnk">https://postimg.cc/q6wHvrcC</a><br>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Regards,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div>
<div id="Signature">
<div>
<div id="divtagdefaultwrapper" dir="ltr" style="color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:12pt">
<p style="margin-top: 0px; margin-bottom: 0px;"></p>
</div>
</div>
</div>
</div>
<div id="appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>De :</b> Norbert Lange <nolange79@gmail.com><br>
<b>Envoyé :</b> jeudi 20 mai 2021 17:39<br>
<b>À :</b> Mathieu Desnoyers <mathieu.desnoyers@efficios.com><br>
<b>Cc :</b> MONTET Julien <julien.montet@reseau.eseo.fr>; lttng-dev <lttng-dev@lists.lttng.org>; Jan Kiszka <jan.kiszka@siemens.com>; Xenomai <xenomai@xenomai.org><br>
<b>Objet :</b> Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Am Do., 20. Mai 2021 um 17:09 Uhr schrieb Mathieu Desnoyers<br>
<mathieu.desnoyers@efficios.com>:<br>
><br>
> ----- On May 20, 2021, at 9:56 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:<br>
><br>
> > ----- On May 20, 2021, at 9:54 AM, lttng-dev lttng-dev@lists.lttng.org wrote:<br>
> ><br>
> >> ----- On May 20, 2021, at 5:11 AM, lttng-dev lttng-dev@lists.lttng.org wrote:<br>
> >><br>
> >>> Am Do., 20. Mai 2021 um 10:28 Uhr schrieb MONTET Julien<br>
> >>> <julien.montet@reseau.eseo.fr>:<br>
> >>>><br>
> >>>> Hi Norbert,<br>
> >>>><br>
> >>>> Thank you for your answer !<br>
> >>>><br>
> >>>> Yes, I am using a Xenomai cobalt - xenomai is 3.1<br>
> >>>> cat /proc/xenomai/version => 3.1<br>
> >>>><br>
> >>>> After the installation, I tested "test tools" in /proc/xenomai/ and it worked<br>
> >>>> nice.<br>
> >>><br>
> >>> Just asked to make sure, thought the scripts usual add some -xeno tag<br>
> >>> to the kernel version.<br>
> >>><br>
> >>>> What do you mean by "it might deadlock really good" ?<br>
> >>><br>
> >>> clock_gettime will either use a syscall (kills realtime always) or is<br>
> >>> optimized via VDSO (which very likely is your case).<br>
> >>><br>
> >>> What happens is that the kernel will take a spinlock, then write new<br>
> >>> values, then releases the spinlock.<br>
> >>> your program will aswell spin (but just to see if the spinlock is<br>
> >>> free), read the values and interpolates them.<br>
> >>><br>
> >>> But if your program interrupts the kernel while the kernel holds the<br>
> >>> lock (all on the same cpu core), then it will spin forever and the<br>
> >>> kernel will never execute.<br>
> >><br>
> >> Just one clarification: the specific locking strategy used by the<br>
> >> Linux kernel monotonic clock vDSO is a "seqlock", where the kernel<br>
> >> sets a bit which keeps concurrent readers looping until they observe<br>
> ><br>
> > When I say "sets a bit", I actually mean "increment a sequence counter",<br>
> > and readers observe either odd or even state, thus knowing whether<br>
> > they need to retry, and whether the value read before/after reading<br>
> > the data structure changed.<br>
><br>
> Looking again at the Linux kernel's kernel/time/vsyscall.c implementation<br>
> of vdso_update_{begin,end}, I notice that interrupts are disabled across<br>
> the entire update. So I understand that the Interrupt pipeline (I-pipe)<br>
> interrupt gets delivered even when the kernel disables interrupts. Did<br>
> you consider modifying the I-pipe kernel patch to change the vdso update so<br>
> it updates the vdso from within an I-pipe virq handler ?<br>
<br>
Yes, I did use an non-upstreamed patch for a while to get things in order:<br>
<a href="https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.xenomai.org%2Fpipermail%2Fxenomai%2F2018-December%2F040134.html&data=04%7C01%7Cjulien.montet%40reseau.eseo.fr%7Cef0b71ac314f4ab2321f08d91ba57c9d%7C4d7ad1591265437ab9f62946247d5bf9%7C0%7C0%7C637571219835495365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dOiRFzeKFQA%2B25R6aqrjL2ZJMkV5c782DSBGiHHoYZc%3D&reserved=0">https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.xenomai.org%2Fpipermail%2Fxenomai%2F2018-December%2F040134.html&data=04%7C01%7Cjulien.montet%40reseau.eseo.fr%7Cef0b71ac314f4ab2321f08d91ba57c9d%7C4d7ad1591265437ab9f62946247d5bf9%7C0%7C0%7C637571219835495365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dOiRFzeKFQA%2B25R6aqrjL2ZJMkV5c782DSBGiHHoYZc%3D&reserved=0</a><br>
<br>
I would prefer just a NMI safe source that might jump back a bit, no matter how.<br>
<br>
> AFAIU this would allow Xenomai userspace to use the Linux kernel vDSO<br>
> clock sources.<br>
<br>
The Xenomai folks are trying to get their next-gen abstraction "dovetail" closer<br>
coupled to the kernel, AFAIR their will be VDSO support and<br>
unification of the clock sources.<br>
<br>
Still need to get stuff running today =)<br>
<br>
Norbert<br>
</div>
</span></font></div>
</body>
</html>