From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ozGMF/5jpmBYWQAAWB0awg (envelope-from ) for ; Thu, 20 May 2021 09:28:30 -0400 Received: by simark.ca (Postfix, from userid 112) id 526DC1F11C; Thu, 20 May 2021 09:28:30 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 084621E54D for ; Thu, 20 May 2021 09:28:29 -0400 (EDT) Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4Fm9Y82gB4z1rRW; Thu, 20 May 2021 09:28:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1621517308; bh=FdFXLAbC8UoZ+orehGiDz/9z1sjXpWj9EgWQq5XBed4=; h=Date:To:Cc:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=cU9QS1li/xY5ZGXNPuRdQ/o9z1ukMobKxoOdGXR+nEVS92vyN+0UWoVM2FC5yYXCJ 706v6XLTm4U6rEQi2U4GgQKrKFfkUGG4Vov3exqXuTM1+76xCLlVBACxi6BMIQEzFo 3GV1Ala8a31PviyNOKU7DM2OT5UoiWUFm4fYE1RS4Je0+4sJho5qnYg1xz+6noNSZ0 H29FHPBaLeeoGIu+gcXDMjKRABVSr6QQlz028Txp/Y8O30SfaZ7e7nhDwP0ID5mrdH irGjCLebittNykFS5GVANJ9M7+Y6sPUqaEmi2cs/2nHKVWOCvb61+OJQqZgUVW6DNA BDwpO1aD8ruyQ== Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by lists.lttng.org (Postfix) with ESMTPS id 4Fm9Y66nzkz1rLp for ; Thu, 20 May 2021 09:28:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 8CA553357A3 for ; Thu, 20 May 2021 09:28:20 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id cFIqtL0NIHSQ; Thu, 20 May 2021 09:28:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id F1C5133546F; Thu, 20 May 2021 09:28:19 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com F1C5133546F X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KfD3PgIkOK66; Thu, 20 May 2021 09:28:19 -0400 (EDT) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id E6609335918; Thu, 20 May 2021 09:28:19 -0400 (EDT) Date: Thu, 20 May 2021 09:28:19 -0400 (EDT) To: Norbert Lange Cc: lttng-dev Message-ID: <1519877397.52210.1621517299822.JavaMail.zimbra@efficios.com> In-Reply-To: References: <217443874.51651.1621450365666.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_4018 (ZimbraWebClient - FF88 (Linux)/8.8.15_GA_4007) Thread-Topic: reading context fields causes syscalls Thread-Index: 8e4HYK2YNMCNcemOdiLoVxwv62jnzQ== Subject: Re: [lttng-dev] reading context fields causes syscalls X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mathieu Desnoyers via lttng-dev Reply-To: Mathieu Desnoyers Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" ----- On May 20, 2021, at 8:46 AM, Norbert Lange nolange79@gmail.com wrote: > Am Mi., 19. Mai 2021 um 20:52 Uhr schrieb Mathieu Desnoyers > : >> >> ----- On May 19, 2021, at 8:11 AM, lttng-dev lttng-dev@lists.lttng.org wrote: >> >> > Hello, >> > >> > Several context fields will cause a syscall atleast the first time a >> > tracepoint is >> > recorded. For example all of the following: >> > >> > `lttng add-context -c chan --userspace --type=vpid --type=vtid --type=procname` >> > >> > Each of them seems cached in TLS however, and most should never change >> > after startup. >> > >> > As I am using Lttng over Xenomai, syscalls are strictly forbidden, I >> > would like to have some function that prepares all data, which I can >> > call on each thread before it switches to realtime work. >> > >> > Kinda similar to urcu_bp_register_thread, I'd like to have some >> > `lttng_ust_warmup_thread` function that fetches the context values >> > that can be cached. (urcu_bp_register_thread should be called there >> > aswell) >> > I considered just doing a tracepoint, but AFAIK the channel can be >> > changed/configured after the process is running. So this is not robust >> > enough. >> >> The new lttng_ust_init_thread() API in lttng-ust 2.13 would be the right >> place to do this I think: >> >> /* >> * Initialize this thread's LTTng-UST data structures. There is >> * typically no need to call this, because LTTng-UST initializes its >> * per-thread data structures lazily, but it should be called explicitly >> * upon creation of each thread before signal handlers nesting over >> * those threads use LTTng-UST tracepoints. >> */ >> >> It would make sense that this new initialization helper also initializes >> all contexts which cache the result of a system call. Considering that >> contexts can be used from the filter and capture bytecode interpreter, as >> well as contexts added to channels, I think we'd need to simply initialize >> them all. > > Yeah, just figured that it doesnt help at all if I do a tracepoint, as > it might just be disabled ;) > lttng_ust_init_thread() sounds right for that, maybe add one or 2 arguments for > stuff you want initialized / dont want initialized over the default. > > I take that the downside of eager initialization is potentially wasted > resources (now ignoring any one-time runtime cost). I would not want to introduce too much coupling between the application and the tracer though. The public API I've added for the 2.13 release cycle takes no argument, and I'm not considering changing that at this stage (we are already at -rc2, so we're past the API freeze). I'd be open to adding an extra API with a different purpose though. Currently lttng_ust_init_thread is meant to initialize per-thread data structures for tracing signal handlers. Your use-case is different: you aim at tracing from a context which cannot issue system calls. Basically, any attempt to issue a system call from that thread after this is a no-go. I would be tempted to introduce something like "lttng_ust_{set,clear}_thread_no_syscall" or such, which would have the following effects when set: * Force immediate initialization of all thread's cached context information, * Set a TLS variable flag indicating that the tracer should not do any system call whatsoever. The tracer could either use dummy data (zeroes), log an error, or abort() the process if a thread in no_syscall mode attempts to issue a system call. This could be dynamically selected by a new environment variable. * Prevent threads in no_syscall mode from calling the write() system call on sub-buffer switch (of course the read-timer channel option is preferred). Thoughts ? 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