From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /G5rDyZapmBGWAAAWB0awg (envelope-from ) for ; Thu, 20 May 2021 08:46:30 -0400 Received: by simark.ca (Postfix, from userid 112) id 305401F11C; Thu, 20 May 2021 08:46: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=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_REPLYTO_END_DIGIT,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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 838E81E54D for ; Thu, 20 May 2021 08:46:29 -0400 (EDT) Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4Fm8ch6sC3z1rTX; Thu, 20 May 2021 08:46:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1621514789; bh=t6Y7IIa+aUe2Bt2H+yNpcjIEvi3zE/K7YvdzWPRa5MA=; h=References:In-Reply-To:Date:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Co6pnlks5Cn7KO6Y0Oa0L7UU6N5iWOQd/7vYyFHcCRCrSSgL9XfTAlMAWyGlDbUxm ZtqP7f32T+Gau1B5RYnErpCZCkNqGkl1KbdOm6VLAWmCPCK66Y5SwTV6jVh7vmWTi5 FYupG1KJB/K237iA78Ese5+5dvkzpUSvlmbtdIJqOhF2TYWLqsg/ubbD8rrRj1VuFb n3XdL9SWo4pqa+dZYDlQgCCwzQzf+fzBPdGcEMFp6iEcG9u5JjbzsakiskHAMjOAgF tbjWhiuHPGIo3O6+yQfHsMGQbtU5yFdwlT3RYSRZLUI7CoVuzvOjFmmhXjTmLiEdsu UMeRfCsccvy3g== Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by lists.lttng.org (Postfix) with ESMTPS id 4Fm8ch4MXWz1rTW for ; Thu, 20 May 2021 08:46:28 -0400 (EDT) Received: by mail-oi1-x22d.google.com with SMTP id t24so761518oiw.3 for ; Thu, 20 May 2021 05:46:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0q2KEmzsBhKrby9HaQ1gAzu5izyc1WZof9FQrcOwsmQ=; b=qtV6p1Zcw9T7fylaz0VJFRbhaGQwzF/dDPviwpRWJ2/jXlspYDyZSDoFkBJ7CwhlHR xBYX3WPkgGlzUSkW0P0IZQOSdFHfrZubCXPeT/Spm5mvdBp/EMImyeoHN/prBypIZInl nwHoOzwYGhvH9UrnKDttMoYHxVZfJ9xdGZSiioPfkqeL4BgoswpCeUDLPx7yNWrtD04R A3cXdpA4y1uth/AMrdEYhGoEtVwTRcbxeJVsdopAUzLAL06e7dqFK23gS6EuHzi5kVaD m+YhYogdIiNRFAJcOXiKA7myni1c40xIms24E95h3W4KvMKACPTcLZ1+vURShmbRiYPz poVA== X-Gm-Message-State: AOAM5339DezQzt9ss2hH5/hBaM6ytUtyDLJg6K2dFuZloNjeNOWolXku c7PqhI3Sz1u/mYmGE7OvNtmq78P86s67tdir/p4EQSYLOnlyYw== X-Google-Smtp-Source: ABdhPJx5lkXTByd0sPUbR9aXB0XhVm0b+1iNH9HpGghkTzplT2UsZe0VxsR5lGumxf+/TI0IGmm/r4LdGkkKjQgk8ag= X-Received: by 2002:a05:6808:1402:: with SMTP id w2mr1956698oiv.72.1621514787811; Thu, 20 May 2021 05:46:27 -0700 (PDT) MIME-Version: 1.0 References: <217443874.51651.1621450365666.JavaMail.zimbra@efficios.com> In-Reply-To: <217443874.51651.1621450365666.JavaMail.zimbra@efficios.com> Date: Thu, 20 May 2021 14:46:16 +0200 Message-ID: To: Mathieu Desnoyers Cc: lttng-dev 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: Norbert Lange via lttng-dev Reply-To: Norbert Lange Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" 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). Norbert _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev