From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YBP2GAQmd2jIHDYAWB0awg (envelope-from ) for ; Wed, 16 Jul 2025 00:09:40 -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=ebzJhUe1; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 5FFB11E11C; Wed, 16 Jul 2025 00:09:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.9 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MIME_QP_LONG_LINE,MPART_ALT_DIFF, RCVD_IN_DNSWL_NONE,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from lists.lttng.org (lists.lttng.org [158.69.130.29]) (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 994D21E0C2 for ; Wed, 16 Jul 2025 00:09:39 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4bhjHk6cXJz23rZ ARC-Seal: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; cv=none; t=1752638979; b=B5uNkmwdho0cZ/KaeFHSeddAyqzmYWaj4MSEPZG+2JnxrBJ996/zU9yABIzo1kzLGwBi aZyfFpiS26zJcGZy0kUg7QgXO0/UUwgFqROumAMGMq1zKqXY6OKgh5LOGtA5eFK1f58oE AHBtUK1F/jabH2aVgn+sHpeP0AcbXGCpULegSVwWQPjm9YtK24Om+TxundEnSuilhI6/u 5SHcH4AnU1x7V8wSTpyDqaDQmM9oasgCxZThnCtaxEhvZHH+WtTL1AeaPlA+n12uOFQLR nfIabTw5husFVsVhfY7yQhtx5yVrv6SAfW5ZD95L6dnTe7XXtgKuRhjghy9IlKRmguQ== ARC-Message-Signature: i=1; d=lists.lttng.org; s=arc1; a=rsa-sha256; c=relaxed/simple; t=1752638979; h=DKIM-Signature:Mime-Version:Date:Subject:Message-Id:To:From:From; bh=yBpfr3f093naAb7ph/5kFXmukZjpAfghSmzd6lRrsLU=; b=Ff2CYLMO2Ujg82FvAktW50hqPTgVnnVj7vELs62MDeAphSDS5N2+tQIuRaTBbDbTpUlu RbPaJYsH4JSLoDSPIgs0Xi0oHbS2k1W9Mrrcineee8zGiQz/s9t6AnLy/WLfn8gxt9o5W tKffExhc7cZRpGfsOIgrlmrFm+EKutv2rs6Kxul7gvWSVbo5ojnyba6TS2IjCxtcX9yQh k2a2EYjf4kkVHRpPVuUVllCGcUvLnP2dOfzX/dgGX/1Adp/8p6e+qH+DVynZdCSV6MLyK REdO1KWf5jiVMDUmMXO1XZXmOk80CYF1mBjvSxN5gyggNGUD16lzWW2I+80U3orQY2A== ARC-Authentication-Results: i=1; lists.lttng.org; arc=none smtp.remote-ip="::1" DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4bhjHk6cXJz23rZ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1752638979; bh=yBpfr3f093naAb7ph/5kFXmukZjpAfghSmzd6lRrsLU=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=ebzJhUe1GpkwMaYIem+kPT4dM2P5BEkflWFDwA3T1T6VWM588OC1BNbIXWo5nRD9L qm/yETGRXbplCmxdPTFIVZEUllsza75DHDcvnPzXZyAiizA0ZPdXTUT5wNlGNGNdtU VxEaHyNw2667bMUCNDzojKRjcku7T1XdFjCpZ9uZ8PRLds18myn+dPfhMWT2tsgL4k AS4VhaiQhBPHwMvT74ciyjFReYUerJnt7GeKI6vouaLBYPDA9wyjFib4paBXCYhQyj 1BlOICw8K7z5Iq1TTwyn5VfzSDVTGR9StRNu/1H/mHrSc0BIT3o3iQotf1HwXV4fln ydHWVXcX1X2lA== Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4bhjHk6cXJz23rZ; Wed, 16 Jul 2025 00:09:38 -0400 (EDT) ARC-Filter: OpenARC Filter v1.2.1 lists.lttng.org 4bhjHj34MBz23rY DKIM-Filter: OpenDKIM Filter v2.11.0 lists.lttng.org 4bhjHj34MBz23rY Received: from fout-a2-smtp.messagingengine.com (fout-a2-smtp.messagingengine.com [103.168.172.145]) by lists.lttng.org (Postfix) with ESMTPS id 4bhjHj34MBz23rY for ; Wed, 16 Jul 2025 00:09:36 -0400 (EDT) Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 76D1BEC010C for ; Wed, 16 Jul 2025 00:09:35 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Wed, 16 Jul 2025 00:09:35 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehieejvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecuqfhnlhihuchonhgvuchprghrthculdehuddmnecujfgurh eptgfghfggfffukffvofesrgejmherhhdtjeenucfhrhhomhepqfhnughrvghjucfuuhhr upcuoehonhgurhgvjhesshhurhihrdhorhhgqeenucggtffrrghtthgvrhhnpedvkeffgf evkeeugefffeejteekgfdvgffgvdejteefhfeffeffveetgffhfeduhfenucffohhmrghi nhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepohhnughrvghjsehsuhhrhidrohhrghdpnhgspghrtghpthhtohep uddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheplhhtthhnghdquggvvheslhhish htshdrlhhtthhnghdrohhrgh X-ME-Proxy: Feedback-ID: ida81469e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 16 Jul 2025 00:09:34 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9E68AFA5-920A-425B-9A53-6E4953BE8C5C Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 16 Jul 2025 06:09:22 +0200 Subject: Integrating QSBR with libuv Message-Id: To: lttng-dev X-Mailer: iPhone Mail (22F76) 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: =?utf-8?q?Ond=C5=99ej_Sur=C3=BD_via_lttng-dev?= Reply-To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" --Apple-Mail-9E68AFA5-920A-425B-9A53-6E4953BE8C5C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

currently= , the BIND 9 design involves multiple threads with per-thread event loop fro= m libuv (uv_loop).

We are using the default rcu var= iant, but it seems like an ideal place to switch to QSBR as we can call quie= scent state periodically before polling on the loop.

This comes with one trouble though. The incoming traffic is distributed us= ing SO_REUSEPORT load-balancing in the kernel and if the hashing algorithm i= s too simple or the traffic just hashes only into 1..n-1 threads, the memory= reclamation will never trigger (means indefinite wait for synchronize_rcu()= or indefinite queue in the call_rcu).

Now, I have b= asically two solutions I can think of:

1. Bring the= threads offline before polling and online after polling. This has two probl= ems: a) there=E2=80=99s overhead related to calling thread_offline/thread_on= line and it is unclear to me how big overhead this is; b) currently, there i= s no way to bring the thread online before libuv callbacks are called - = ;https://github.com/libuv/libuv/issues/4839

= 2. Add short per event loop periodic timer that would call the quiescent sta= te every <n> ms, but I have a vague recollection that unneeded periodi= c timers mess with the power management as they wake up the process even whe= n it would be otherwise completely idle.

The bonus t= hird option is to give up on this because there are lower hanging fruits to i= mprove the performance than the membarrier vs QSBR. That=E2=80=99s certainly= true, but it is an interesting software engineering problem, so I am not re= ady to give this up easily ;). And coming up with a solution to this could l= ead to at least a blog post that more project could benefit from a solution t= o this. (For a moment, pausing from the grim world we live in now where ever= y idea gets sucked into LLM and venture capital.)

Ondrej=
--
Ond=C5=99ej Sur=C3=BD (He/Him)<= /div>
= --Apple-Mail-9E68AFA5-920A-425B-9A53-6E4953BE8C5C--