From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 764ED379999 for ; Thu, 8 Jan 2026 08:39:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767861585; cv=none; b=YlCtfovmKpSPQX2/HoEHMffkUshW9W9mixCLLTnGA3KJ1j1rj0rs0/ymg5txZCMUtVEhioWgtkHhOR5bEb47t3YS7HAhCTpQhLj+EqQDN/AIniiLAB5A7Difu/lDyMkVzodxSBPzfsQTHW/CMUhmWL0mwL7YmYUE3cUxgkuNgOQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767861585; c=relaxed/simple; bh=KBSq5ozp9nWK7xE1oaTKEnG55tvkaczknOCnKuHL4hY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=GbkLC1MRnPaLSA/549pp2BywNYkhxgLwpS4F6vtm0PbFxH/GhqBItcl+cdF7mfbANYxp7YRvc8FJUj19arB74gVstORyLR9YzvkQT9DbkYdyHa07jmSxUXoaJZTcO5c5TZKSrxeWIjTY/VsQqSrm43+Ofr/Wr46k4HUEZR3pspg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=QLyOhSyT; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="QLyOhSyT" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-43263e1ce4eso236077f8f.1 for ; Thu, 08 Jan 2026 00:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767861575; x=1768466375; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=n/vUisi3Mqmn3VVAgeiq/GIYmN1ZatSlGnG9ei2N00E=; b=QLyOhSyT24mR2/QzuAdbUodu/les2P483pjlQ5n5yVmXv5SsjX+vubuafITUKtCmj3 tqkhi8BlZRtxhpRjbDfbciJaUtheKJyK/0OjFOhh1RvDz2o58nq8O1uFhizXeB2YgtSl byWkBkMtbPN6/i9SgzO177RAw63cXm4xijv6N70USAcDMk6vnvbbT5IU6ezjf+ND2j13 WCA29Gv/j0/Efgez5FqbIfZiEAlTY4WXvb4d/frUAd75qiV/o06wtIEbyZmHl4OUPnmf XFbZBmkbCk3PTmY8E0vDie9vvD3NLaQxP+BScnru/Y9JzMENmxAPzmfTvT9TTbMLvyfn OswA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767861575; x=1768466375; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=n/vUisi3Mqmn3VVAgeiq/GIYmN1ZatSlGnG9ei2N00E=; b=nB6bpbHluDDMWzEe1GfEePpIz+pfKp/lyPsPWfWjl7ra0f9KEMzQ4qXs9J/BNx5nQo 1W7fZwgt6GFqV9Zrio3Q3MeoVAyfXuZzBlMibWVo+G/VxGIVR6dVYzZUw4WAr90hBlp9 QJ11HwGiJTpGRBfzeRE0rCbzOc+rUTZ+Jt704dZIfpwnpw0x8qpSMMZ8g3xmfjZdeLsJ usvrCWjY79omCGWidMHHQS9UEJx/xx/4Q49xCqIHJTPwviS/yT2lPFpxf4r8fJ7CTlha ceMJtUb5geZzDD+8BnnZ9T0q2pV/tpwkNHkCW2SYSNivdwzIWZI6I5RLXGbswAg59psw jUwQ== X-Forwarded-Encrypted: i=1; AJvYcCVTpCE2BAaUJP3ZKdLLAGMK7+OgBOvLUfatQ2tJf7Od3X5/DC+svydTNtkEh2xqA8BBz1AOXV+WBmemmaE=@vger.kernel.org X-Gm-Message-State: AOJu0YzXYx+zhq3PxVaqL1deXxxfhmxfbmhrkAA6OmlIr+LGLTX7B27y L/i8HkMFnkyyF6LWPRxMlORXiORL5szo6DNnO+rPnmMgiUncW9km/eRfpKcpg2+cWf4= X-Gm-Gg: AY/fxX7l7/whOwkM0vk0Ts0ArO3V0uLXi6H5rvGBLlhZbhT6RljQWGab6KVSJ/hpR0P vBSCqSN20PIMmyCi8wZ/YUMgNigdzEhIoyoBZPYrue0dfFeAQf1aWvj4OqedTMgJZgGOD2aVmKG yvDJzL6j3IpDzDWY2zKCBozprWkZhIYnv0JQdbY0qNy0k8G3XeMgffDtASMTsK52MGkyw1foX9a XBuw2ztW7hy67hhfkOdFSCcNCSpi2gFZDuAuFDKemSwrtN05O5vg3anrFWIkp9IGBbHaCh/PhnQ 8wuXjC1TwxwaH/erjl8Sx+qywnRIgTKj71JBh/Eic5T+SBLRQqCwUNpMFGIb7B4s0yYgJjY5E1H sBQdwoWy83oJAcW1CXDD78s1wlXAff5XukuWuEIwOlCA0UwWnHBD6QxuTccgaENLf+wJjW6fSes MT0aNxdiZw84x83h7/zOYpakYRc+EdthedqYIqXsqerP23BaMt6gfChxin5uHnIzmAL1elX6hos +nV X-Google-Smtp-Source: AGHT+IE+AxG15zz8e6XqsM+Ihev+zYB7TD2+tvKX+z3mSuMcV9zIClsWCLuPxib3hoIzZay0GziECg== X-Received: by 2002:a05:6000:2c0c:b0:431:66a:cbcb with SMTP id ffacd0b85a97d-432c37c1eddmr3835457f8f.7.1767861574850; Thu, 08 Jan 2026 00:39:34 -0800 (PST) Received: from mordecai (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5fe83bsm15596057f8f.38.2026.01.08.00.39.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jan 2026 00:39:34 -0800 (PST) Date: Thu, 8 Jan 2026 09:39:32 +0100 From: Petr Tesarik To: Steven Rostedt Cc: Masami Hiramatsu , Mathieu Desnoyers , Sebastian Andrzej Siewior , Clark Williams , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH] ring-buffer: Use a housekeeping CPU to wake up waiters Message-ID: <20260108093932.252f6bc7@mordecai> In-Reply-To: <20260107111935.3befc296@gandalf.local.home> References: <20260106091039.2012108-1-ptesarik@suse.com> <20260106170405.425f469e@gandalf.local.home> <20260107085009.58fcffd4@mordecai> <20260107105137.4cf9a67e@mordecai> <20260107111709.0d115cd8@gandalf.local.home> <20260107111935.3befc296@gandalf.local.home> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-suse-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 7 Jan 2026 11:19:35 -0500 Steven Rostedt wrote: > On Wed, 7 Jan 2026 11:17:09 -0500 > Steven Rostedt wrote: > > > Or we simply change it to: > > > > static inline void > > Actually, the above should be noinline, as it's in a slower path, and > should not be adding logic into the cache of the fast path. However, to be honest, I'm surprized this is considered slow path. My use case is to record a few selected trace events with "trace-cmd record", which spends most time polling trace_pipe_raw. Consequently, there is almost always a pending waiter that requires a wakeup. In short, irq_work_queue() is the hot path for me. OTOH I don't mind making it noinline, because on recent Intel and AMD systems, a function call (noinline) is often cheaper than an increase in L1 cache footprint (caused by inlining). But I'm confused. I have always thought most people use tracing same way as I do. > > rb_irq_work_queue(struct rb_irq_work *irq_work) > > { > > int cpu; > > > > /* irq_work_queue_on() is not allowed in NMI context */ > > if (in_nmi()) { > > irq_work_queue(&irq_work->work, cpu); > > return; > > } Thanks for the idea. There are some downsides. IIUC there is no fundamental reason IPIs to other CPUs cannot be sent from NMI context. It's just a limitation of the current Linux kernel code. As such, it may be lifted in the future, and at that point nobody will remember to remove this condition. My current plan is it to keep the patch on hold and have a look why IPI backends are not NMI-safe. In fact, I'm not even 100% sure the comment is correct. The issue may have fixed itself e.g. by removing the last affected architecture. ;-) Petr T