archive mirror
 help / color / mirror / Atom feed
From: Mathieu Desnoyers via lttng-dev <>
To: Norbert Lange <>
Cc: MONTET Julien <>,
	 lttng-dev <>
Subject: Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()
Date: Thu, 20 May 2021 09:54:34 -0400 (EDT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

----- On May 20, 2021, at 5:11 AM, lttng-dev wrote:

> Am Do., 20. Mai 2021 um 10:28 Uhr schrieb MONTET Julien
> <>:
>> 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: 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.



Mathieu Desnoyers
EfficiOS Inc.
lttng-dev mailing list

  reply	other threads:[~2021-05-20 13:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20  7:58 MONTET Julien via lttng-dev
2021-05-20  8:20 ` Norbert Lange via lttng-dev
2021-05-20  8:28   ` MONTET Julien via lttng-dev
2021-05-20  9:11     ` Norbert Lange via lttng-dev
2021-05-20 13:54       ` Mathieu Desnoyers via lttng-dev [this message]
2021-05-20 13:56         ` Mathieu Desnoyers via lttng-dev
2021-05-20 15:09           ` Mathieu Desnoyers via lttng-dev
2021-05-20 15:34             ` Jan Kiszka via lttng-dev
2021-05-20 15:39             ` Norbert Lange via lttng-dev
2021-05-21 10:13               ` MONTET Julien via lttng-dev
2021-05-25  8:46                 ` Norbert Lange via lttng-dev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).