From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id M/jzMrlAUWpyCgIAWB0awg (envelope-from ) for ; Fri, 10 Jul 2026 14:58:01 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=lists.lttng.org header.i=@lists.lttng.org header.a=rsa-sha256 header.s=default header.b=wu4IRzYf; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BC78B1E098; Fri, 10 Jul 2026 14:58:01 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=4.0.1 Received: from lists.lttng.org (lists.lttng.org [IPv6:2607:5300:400:ed00::6c26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 662481E070 for ; Fri, 10 Jul 2026 14:58:00 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4gxh133fXjz18Rl ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1783709880; b=DXw6kM5mHEsXaYFiZVEhsQcD8u9847eTfsXuQXsRjMZ2nb49FoYQ9/jBOA2vy/x5vbVy 7hg+Bq8mYbGY00pJDEJBBEipuiuQRyeQqJN6NaFDoMBAbEMsULdy4sy3YL2F6/LLWnzCA OIKWZLsiZHsws0zNSHcFn8p0EEM9BCtJnt8+ATLjdOKy9sBf12fFdn5qHwZ821g5f28Ak xR9jjgYqNOXSkhnGB6aTLOSm+eT4DAA2u4N7D9xwcNXqrk/hZ7UoGSGO52hmhDIDxjN1R cOsmUNZ7S168u5KUW6zetfSyy8LHQciYhqA+LaCR3/Rbb3CMXoIDQcwn5yu6JZugOJg== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1783709880; h=DKIM-Signature:Date:To:Subject:Message-ID:MIME-Version:From:From; bh=H/1nZFPAPaL8u258fAFdTfJ9LqkIDbztbA7siY2WH/Y=; b=nx90RG2yqndPlLibYi6vQOL0qOYNx5aVEmHL3vrLprLYDIuMFyhygl5d4OC1MNeVQamS I+g2PVXhhSStF0fi/iw7TR9kv5lkFkiZPQ+2NRloxzfJGUQOWE12xPXtY+NCge/M0KLWK fHXZ/8iAeAhm2oKAUFO+DRiRDKy3ZkYIbaM2VhqwZN0caqOmZ8gYQvTlVVowH0JnQ/yyy XBhDqZ92n0llWwhYPI0REbNDLJHHE1Jt8Ilt9TWAFBMkALbHkQbiezrBAcSuJ8Pfs18Tn 3mh5QPE1CjqtnLjYRu2tliZENwvqej99rHm5sJAJo+9xNVN714CEWsOeIjtOV5r0Bdg== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4gxh133fXjz18Rl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.lttng.org; s=default; t=1783709880; bh=cs43+sY+FfljqfKLFyTLcca/NrAozLY9ZTEKE74lCVw=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=wu4IRzYfB/lsty+w/kSiInFlMM5YPx4CwSfAqcelj8yKBC+Q6JiiAvG6KKFFkF0DM ibDglt9vMTKKj6KZj5cOlzOIg41TkXBheyMlqaO42E7ybeO4DvM+tKNrmCu0KJbNNd J3UBJC0tSJ6xdR8cyNYaSiJurzHnALxb6Eh3qYs0VbwOL4OPf5oGIHzylaQaaWR3NV k0291Wzk6PEjpYdDLKSEocxo3ZhiP5KxEq7QFkOObnUwL6AdzNO9YUzXNgz3CYPVac OTeo5d1tF1bGqPqGp2d0Cc5R9wfWzOwnXtUK0oPF13pt8Om8sR51cy/5HUijnnD050 dfbgMMykSwe3A== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4gxh133fXjz18Rl; Fri, 10 Jul 2026 14:57:59 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4gxh1122cTz18Rk DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4gxh1122cTz18Rk Received: from sea.source.kernel.org (sea.source.kernel.org [IPv6:2600:3c0a:e001:78e:0:1991:8:25]) by lists.lttng.org (Postfix) with ESMTPS id 4gxh1122cTz18Rk for ; Fri, 10 Jul 2026 14:57:57 -0400 (EDT) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 13C3342D54; Fri, 10 Jul 2026 18:57:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBFA21F000E9; Fri, 10 Jul 2026 18:57:53 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id BF7BFCE084A; Fri, 10 Jul 2026 11:57:53 -0700 (PDT) Date: Fri, 10 Jul 2026 11:57:53 -0700 To: Mathieu Desnoyers Cc: lttng-dev , Olivier Dion Subject: Re: CPU affinity behavior of liburcu call-rcu per-cpu worker threads Message-ID: <8d48389d-5cf8-46b1-a6da-7738e11e3737@paulmck-laptop> References: <0600b601-3edf-4897-b319-b4763943809c@efficios.com> <3573944e-3abc-48d7-aedf-3362ebd7ebe4@paulmck-laptop> <38f1f93e-3bfa-425a-96d9-3035c8ecc785@efficios.com> <1aaa979b-bad9-47a5-879b-b4fb2379ad20@paulmck-laptop> <02709be9-d7d8-47cc-8032-ed2e3a714fb0@paulmck-laptop> <14541751-5104-483b-b60c-415d791b4bf4@efficios.com> <95f2d189-ebe2-47f1-91db-c964f2cda8a7@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Paul E. McKenney via lttng-dev" Reply-To: paulmck@kernel.org Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" On Fri, Jul 10, 2026 at 12:17:39AM -0400, Mathieu Desnoyers wrote: > On 2026-07-10 00:07, Paul E. McKenney wrote: > > On Thu, Jul 09, 2026 at 10:56:51PM -0400, Mathieu Desnoyers wrote: > > > On 2026-07-09 22:53, Paul E. McKenney wrote: > > > [...] > > > > > > > > > And unfortunately, for me, tcmalloc is really not a viable option, > > > > > because it needs to own the RSEQ area registration, and because glibc > > > > > cannot use it at the same time as tcmalloc, my benchmarks suffer because > > > > > glibc has a slower sched_getcpu() implementation. > > > > > > > > > > So jemalloc it is. tcmalloc is not usable for me because they don't > > > > > compose with the rest of the world. I warned the tcmalloc developers > > > > > many times, but they did not listen. :-( > > > > > > > > So an alternative rseq for the rest of us? > > > > > > I'm not quite sure I understand. Since there is only one rseq > > > registration per thread, this means that tcmalloc require their > > > users to use a GLIBC tunable to disable rseq registration at the > > > libc level, leaving rseq solely to tcmalloc. > > > > Could an independent thing very closely resembling rseq be brought into > > being alongside the current rseq, so that tcmalloc gets the existing > > one and everyone else plays nice and shares the new one? > > That would unfortunately roll the clock backward about 5 years in terms > of glibc integration, which supports rseq out of the box since version > 2.35 (Feb 2022). > > Moreover, if we add a second rseq area, this means the kernel now need > to have code to support both areas in key performance-critical code > areas (scheduler, interrupt entry/exit). > > So no, as far as I am concerned, this is really not an option. > > The "simpler" option would be to implement the rseq extension tcmalloc > need, so they can finally stop doing their odd games and become > compatible with the rest of the world. But the last time I offered to > help them on this front I've been told that they would not even have > time to try my patches. > > Oh well. I bet that there is a way, but thus far I at least add a load and a branch to those fastpaths. Maybe convince someone to submit the needed patches to tcmalloc() and then browbeat the tcmalloc() folks into accepting them? You would need someone young, energetic, and obnoxious, which lets me off on two of the three. ;-) Thanx, Paul