From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: lttng-dev <lttng-dev@lists.lttng.org>,
MONTET Julien <julien.montet@reseau.eseo.fr>
Subject: Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()
Date: Thu, 20 May 2021 09:56:50 -0400 (EDT) [thread overview]
Message-ID: <201689209.52304.1621519010729.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <851697925.52293.1621518874455.JavaMail.zimbra@efficios.com>
----- 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.montet@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
next prev parent reply other threads:[~2021-05-20 13:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 7:58 [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read() 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
2021-05-20 13:56 ` Mathieu Desnoyers via lttng-dev [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201689209.52304.1621519010729.JavaMail.zimbra@efficios.com \
--to=lttng-dev@lists.lttng.org \
--cc=julien.montet@reseau.eseo.fr \
--cc=mathieu.desnoyers@efficios.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).