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