----- On May 20, 2021, at 5:11 AM, lttng-dev lttng-dev@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 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-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
