From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 22 Nov 2019 10:09:33 -0500 (EST) From: Mathieu Desnoyers Message-ID: <1116885999.789.1574435373841.JavaMail.zimbra@efficios.com> In-Reply-To: <4544332f-e10b-8f3a-64f4-4dd47996ab91@siemens.com> References: <5718dcc6-9af6-03f8-3e44-b91805f403e2@siemens.com> <4544332f-e10b-8f3a-64f4-4dd47996ab91@siemens.com> Subject: Re: urcu/lttng (Userspace) and Xenomai MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Lange Norbert , "Xenomai (xenomai@xenomai.org)" ----- On Nov 21, 2019, at 11:19 AM, Jan Kiszka jan.kiszka@siemens.com wrote= : > On 21.11.19 15:15, Lange Norbert wrote: >>> -----Original Message----- >>> From: Jan Kiszka >>> Sent: Donnerstag, 21. November 2019 14:46 >>> To: Lange Norbert ; Xenomai >>> (xenomai@xenomai.org) >>> Subject: Re: urcu/lttng (Userspace) and Xenomai >>> >>> NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR >>> ATTACHMENTS. >>> >>> >>> On 21.11.19 11:26, Lange Norbert via Xenomai wrote: >>>> Hello, >>>> >>>> I am trying to figure out if Xenomai would work correctly with Lttng. >>>> Currently I haven=E2=80=99t figured out how the system manages buffers= , but I am >>> checking if this would be generally applicable to Xenomai. >>>> >>>> I=E2=80=99d like to know if anyone has already used Lttng UST with xen= omai >>>> threads, and if there is any need to compile lttng/liburcu for xenomai= or >>> using some patches. >>>> (I haven=E2=80=99t seen anything that indicates it would not work). >>>> >>>> ## urcu flavours >>>> This has a few variants, lttng uses the bulletproof one. Most others >>>> should be faster on average =E2=80=93 but all of them might unlock a f= utex with a >>> raw syscall. >>>> >>>> Other flavours like qsbr could likely be faster if the futex sycall >>>> would be replaced with a cobalt mutex (it=E2=80=99s very unlikely this= path is >>> executed). Would need some work to get this done (and lttng to use it). >>>> >>>> ## sys_membarrier >>>> recent kernels and liburcu versions support this syscall, which >>>> supposedly allows removal of reader memory barriers. >>>> The syscall will somehow interrupt the threads (all *running threads* = of >>> the process), which implicitly causes a barrier for readers. >>>> >>>> Q: I guess this will *not* interrupt xenomai threads, as their shadow = linux >>> thread is not *running*? >>>> Q: x86_64 accesses are strictly ordered, do you actually need membarri= ers >>> at all? >>>> >>> >>> I didn't look into details of enabling userspace lttng yet, but I had a= chat >>> with >>> Mathieu about this, maybe a year ago. He said back then that there is a= lso a >>> polling mode where a data collection thread is simply trying to obtain = the >>> trace output time-driven. >>=20 >> I believe that=E2=80=99s the "bulletproof" rcu mode that lttng uses. I d= on=E2=80=99t see any >> OS-level >> synchronization in the readers, only some atomic variables. >> Mathieu is a lttng dev? >=20 > Mathieu Desnoyers is the creator of lttng. And of those nice urcu > services and syscalls. Let's try to pull him in... :) Hi Jan, Thanks for putting me in contact. I've seen that Lange started a email thread on lttng-dev. I will reply there for posterity. :) Thanks! Mathieu >=20 > You could also try to place your questions on some lttng channel, I guess= . >=20 >>=20 >>> Then the producer (including cobalt threads) would >>> not need any syscall at all. >>=20 >> In the context of lttng those are readers (of the shared rcu structures)= , >> writes would only happen if tracepoint providers are added/removed. >=20 > Maybe Mathieu had a static (upfront to application start) tracepoint > configuration in mind. That's what I would expect from an RT setup at lea= st. >=20 >>=20 >> But then I don=E2=80=99t know how the buffers are managed, this appears = to >> be system-wide in another process. >>=20 >> The sys_membarrier syscall would be called by writers (not xenomai threa= ds) to >> additionally allow >> instructions like dmb (for arm) around atomic accesses to be removed for= the >> readers. >> I think it's useless for x86_64 and the syscall itself would not do anyt= hing for >> running xenomai threads. >> (you can only force the syscall but not disable it, without changing sou= rces >> that is). >=20 > While an x86-only view can be ok for a concrete setup, it's better to > develop a generic / portable solution that enables lttng for broader use > in Xenomai applications. >=20 >>=20 >>> As I said, that was just a conceptual discussion. >>> None of us actually looked into the implementation. >>=20 >> Hmm, would like to test this soon. Still need a way to totally disable i= t >> in-case something goes wrong.. ie ugly macro magic. >> Can you tell me that I am right about >> membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED) not blocking until >> the running xenomai thread had some sort of syscall synchronization? >=20 > I haven't looked into membarrier semantics in Xenomai context yet. The > key question is if the Xenomai task switcher happens to provide the same > information to that service as a normal Linux task switch would do. > Maybe it's working, just slower, maybe it's stalling with CPUs that only > switch between Linux idle and the Xenomai scheduler as a black box from > Linux perspective. >=20 > Jan >=20 > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux --=20 Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com