From: Mathieu Desnoyers via lttng-dev <firstname.lastname@example.org> To: Mathieu Desnoyers <email@example.com> Cc: lttng-dev <firstname.lastname@example.org>, MONTET Julien <email@example.com> 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.firstname.lastname@example.org> (raw) In-Reply-To: <851697925.52293.1621518874455.JavaMail.email@example.com> ----- On May 20, 2021, at 9:54 AM, lttng-dev firstname.lastname@example.org wrote: > ----- On May 20, 2021, at 5:11 AM, lttng-dev email@example.com wrote: > >> Am Do., 20. Mai 2021 um 10:28 Uhr schrieb MONTET Julien >> <firstname.lastname@example.org>: >>> >>> 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 > email@example.com > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list firstname.lastname@example.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 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.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()' \ /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
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).