From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uSnNIZleUGrJKAEAWB0awg (envelope-from ) for ; Thu, 09 Jul 2026 22:53:13 -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=s0WADSqt; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7655B1E04F; Thu, 09 Jul 2026 22:53:13 -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 E80B01E04F for ; Thu, 09 Jul 2026 22:53:11 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4gxGbq44YXzyfL ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1783651991; b=XoI2T67e5Mo9VgX6kNI69aux6x3FLcWGKV9pRAmXchalcYx90IRwWcEeWaIT7TjAwkce nZ4h5SCceJfnITIntSmWBwDjfSxSe9eAh+EEVYm1JYDu8GGBB57ytA4wfSC+3RLU6H0l8 3Cse9LeW5RaWrTbBMdBkd4bEdTkHHpfEHAp4GzyYckXMhsHnfe2PxtVIHSaHd/pxr8QRO aDJh7iYEYGND/b5VYwbQ9YonbMO9O5fhzqCTHUHqsIpdBbq7n9ovO2q8ItsoyDQVEwXxR YoLJF0cVYmUiB8ENGd/Q+ND3Dqew0WsReYn9zKp0m3SfT6gPDhVkkuMdBfY9tkAKYaA== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1783651991; h=DKIM-Signature:Date:To:Subject:Message-ID:MIME-Version:From:From; bh=9kWe9g4eEXcu9jZ7VFsACZFesxjz8l9t6IJqfDGM2e8=; b=QwaoNoSqQKqjcyxEBEHHNKNhe0uJgAfCyRsW4VOoQWWajAl2p5mzVCz0ZLSHvct7YZvJ q73JjWoJne3UXqB0C1Xp3edIKBNeCheUDcJEMaOyYdMRocZpXPCCUxaOaP7vjg0HRIjTT Dtzxrjzd/xnwv+bW4Dp2flkJDhSmMuor2dwKJ3qViwwKVzqDFRFIAU4EJM7GTQ6tsASaC l9Z+mSnM7CjIn9C8R+8FWaRAd+p/3I66MaJ9CntiMyfftH3d7yEUU3OGE6FQMTwWOIfg2 4tRTi9CIAJJCnQvDlCJt1No1Z5ud9FtTtLv/1UklpKa7DOvyhoQ4h/KF0N+/24gGZ1g== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4gxGbq44YXzyfL DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.lttng.org; s=default; t=1783651991; bh=+7teTaxKrIuVAZ+YXbluDYul0HIclna7r0C3rzbv98Y=; 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=s0WADSqtPHz6eTjREK+yvVfhuYF1tfa/c1QCQ9/5FsBaLD0ESCuBcd8Z71rgGkpVi R+E1BmtOVngbLkWHT3FMx2TD+Er9Hd4C9OQ/weOhSFmV3rHmWkGXBricqD5jMh2vBU V0ccRPdHacDrYzlRt/sArtvCXDcAMajGyXLyDiMEcxUOaIr2dAGDJqLcfE6Uz9oWEt dEQuXYHGX5Dhd6RXt+lwmbudH1I3P8HxaNsCxGoEQUpS3VA+vXQHAsTQeO1RAe4Yqs cvy9Uq4cdUetn6gpZOIIzyquKMkYp1CsXRwgTZ2fWXGl18f2aXHnfxEVtGnD13evEr OH/M7HgC0nCbg== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4gxGbq44YXzyfL; Thu, 9 Jul 2026 22:53:11 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4gxGbp27Kwzyn3 DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4gxGbp27Kwzyn3 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by lists.lttng.org (Postfix) with ESMTPS id 4gxGbp27Kwzyn3 for ; Thu, 9 Jul 2026 22:53:09 -0400 (EDT) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 7834943870; Fri, 10 Jul 2026 02:53:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C2F81F000E9; Fri, 10 Jul 2026 02:53:07 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 2C41ACE0F42; Thu, 9 Jul 2026 19:53:07 -0700 (PDT) Date: Thu, 9 Jul 2026 19:53:07 -0700 To: Mathieu Desnoyers Cc: lttng-dev , Olivier Dion Subject: Re: CPU affinity behavior of liburcu call-rcu per-cpu worker threads Message-ID: <02709be9-d7d8-47cc-8032-ed2e3a714fb0@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> 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 Thu, Jul 09, 2026 at 07:31:18PM -0400, Mathieu Desnoyers wrote: > On 2026-07-09 19:13, Paul E. McKenney wrote: > [...] > > > > > I am reminded of a DYNIX/ptx feature that allowed you to say that a > > > > pair of userspace threads were related, so that they should be migrated > > > > together. This idea did not go over well during the initial Linux-kernel > > > > scheduler discussions a quarter century back. ;-) > > > > > > I don't really need to have the call-rcu worker related to specific > > > tasks, but I do care that it's local to (at least) a core. I have a > > > high-churn workload which quickly recycles per-cpu slab memory, and > > > in order to get good performance with it I need: > > > > > > - Per-cpu slab cache, > > > - Per-cpu (or at least per core) call-rcu worker threads, > > > > > > Which keeps all the alloc -> call-rcu -> worker -> free churn local > > > to a CPU. > > > > So tcmalloc()? And extensions to rseq to allow something else to use > > it concurrently. Or modifications to tcmalloc() to play nicely. :-/ > > I created my own per-cpu "cache" with a wfstack list in a liburcu > feature branch. It works with all allocators :) Been there, done that! ;-) > 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? > > > The task pairing you hint at would be great for the per-thread > > > call-rcu workers we support in liburcu, but as you say it's easier > > > said than done. > > > > It worked great in DYNIX/ptx! Which was admittedly way simpler than > > Linux currently is. ;-) > > > > > Another approach which would be interesting to look into is to > > > somehow attach the call-rcu workers to rseq mm_cid concurrency > > > ids. > > > > So that a given invocation of call_rcu() queues to the current CPU's > > call_rcu() worker thread? That sounds like a way to obtain what I was > > asking for above. As you said, easier said than done. > > Yes, the advantage is that you would only need to keep around one call > rcu worker thread per _concurrently used_ cpu, rather than per-possible > CPUs. And you would have one call-rcu list per concurrency ID. > > Currently the max number for concurrency ids in a process is limited by > min(nr_threads, hweight(affinity mask)). > > And I still have future plans to implement a cgroup cpu.max.concurrency > file, but I did not get there yet. These do sound like good improvements! Thanx, Paul