----- On May 20, 2021, at 9:56 AM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote:
> ----- On May 20, 2021, at 9:54 AM, lttng-dev lttng-...@lists.lttng.org wrote: > >> ----- On May 20, 2021, at 5:11 AM, lttng-dev lttng-...@lists.lttng.org wrote: >> >>> Am Do., 20. Mai 2021 um 10:28 Uhr schrieb MONTET Julien >>> <julien.mon...@reseau.eseo.fr>: >>>> >>>> Hi Norbert, >>>> >>>> Thank you for your answer ! >>>> >>>> Yes, I am using a Xenomai cobalt - xenomai is 3.1 >>>> cat /proc/xenomai/version => 3.1 >>>> >>>> After the installation, I tested "test tools" in /proc/xenomai/ and it >>>> worked >>>> nice. >>> >>> Just asked to make sure, thought the scripts usual add some -xeno tag >>> to the kernel version. >>> >>>> What do you mean by "it might deadlock really good" ? >>> >>> clock_gettime will either use a syscall (kills realtime always) or is >>> optimized via VDSO (which very likely is your case). >>> >>> What happens is that the kernel will take a spinlock, then write new >>> values, then releases the spinlock. >>> your program will aswell spin (but just to see if the spinlock is >>> free), read the values and interpolates them. >>> >>> But if your program interrupts the kernel while the kernel holds the >>> lock (all on the same cpu core), then it will spin forever and the >>> kernel will never execute. >> >> Just one clarification: the specific locking strategy used by the >> Linux kernel monotonic clock vDSO is a "seqlock", where the kernel >> sets a bit which keeps concurrent readers looping until they observe > > When I say "sets a bit", I actually mean "increment a sequence counter", > and readers observe either odd or even state, thus knowing whether > they need to retry, and whether the value read before/after reading > the data structure changed. Looking again at the Linux kernel's kernel/time/vsyscall.c implementation of vdso_update_{begin,end}, I notice that interrupts are disabled across the entire update. So I understand that the Interrupt pipeline (I-pipe) interrupt gets delivered even when the kernel disables interrupts. Did you consider modifying the I-pipe kernel patch to change the vdso update so it updates the vdso from within an I-pipe virq handler ? AFAIU this would allow Xenomai userspace to use the Linux kernel vDSO clock sources. Thanks, Mathieu > > Thanks, > > Mathieu > >> a consistent value. With Xenomai it indeed appears to be prone to >> deadlock if a high priority Xenomai thread interrupts the kernel >> while the write seqlock is held, and then proceeds to loop forever >> on the read-side of the seqlock. >> >> Note that for the in-kernel tracer clock read use-case, which >> needs to be able to happen from NMI context, I've contributed a >> modified version of the seqlock to the Linux kernel: >> >> https://lwn.net/Articles/831540/ The seqcount latch lock type >> >> It basically keeps two copies of the clock data structures, so the >> read-side never has to loop waiting for the updater: it simply gets >> redirected to the "stable" copy of the data. >> >> The trade-off here is that with the latch lock used for clocks, a >> reader may observe time going slightly backwards between two clock >> reads when reading while specific clock rate adjustments are made >> by an updater. The clock user needs to be aware of this. >> >> Thanks, >> >> Mathieu >> >> -- >> Mathieu Desnoyers >> EfficiOS Inc. >> http://www.efficios.com >> _______________________________________________ >> lttng-dev mailing list >> lttng-...@lists.lttng.org >> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com