From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2E92C61D85 for ; Tue, 21 Nov 2023 16:50:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231143AbjKUQuw (ORCPT ); Tue, 21 Nov 2023 11:50:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229566AbjKUQus (ORCPT ); Tue, 21 Nov 2023 11:50:48 -0500 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7893D110; Tue, 21 Nov 2023 08:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=6odFJeiXcQD3LfuiM3sCn8ULJICyJcyaRaylnyp1q5U=; b=kg63EaZjq/SCXMrF+Q3WDSW7sP Fp7ixQBxsr9IqTxEqnmzSaEvkgBs1agdu70Tam4ja/im1QIJ7VuhTUbQeSDgTIYTUpVOt06U6hmIu OTkcxULSDfFgbMkplWILqAmb9WFh9bAKo3NJ+9yG48l6eq/A2WnPEt8PoZ0oFnbUCp9qFfsIgLGUI tsXnOh8Fm1QD3vQCrl5RUgd+fXYuv86vPDqYSf3E74zzUHbjcpksPeE7XBsBjP3Q1A/LsjER39hpY gVW2i7Tt7+4hUgmTc6dRLBu2jcvx2F2YSiRbQqjP/LGJ/p6wNjAi6GkCZaQ+BdVxQyg87rUgIc7V5 IVXi6+zQ==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1r5TxG-00BV8m-09; Tue, 21 Nov 2023 16:50:30 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 48B1B300338; Tue, 21 Nov 2023 17:50:29 +0100 (CET) Date: Tue, 21 Nov 2023 17:50:29 +0100 From: Peter Zijlstra To: Mathieu Desnoyers Cc: "Paul E. McKenney" , Steven Rostedt , Masami Hiramatsu , linux-kernel@vger.kernel.org, Michael Jeanson , Alexei Starovoitov , Yonghong Song , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , bpf@vger.kernel.org, Joel Fernandes Subject: Re: [PATCH v4 1/5] tracing: Introduce faultable tracepoints Message-ID: <20231121165029.GL8262@noisy.programming.kicks-ass.net> References: <62c6e37c-88cc-43f7-ac3f-1c14059277cc@paulmck-laptop> <20231120222311.GE8262@noisy.programming.kicks-ass.net> <20231121084706.GF8262@noisy.programming.kicks-ass.net> <20231121143647.GI8262@noisy.programming.kicks-ass.net> <6f503545-9c42-4d10-aca4-5332fd1097f3@efficios.com> <20231121144643.GJ8262@noisy.programming.kicks-ass.net> <20231121155256.GN4779@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 21, 2023 at 11:00:13AM -0500, Mathieu Desnoyers wrote: > On 2023-11-21 10:52, Peter Zijlstra wrote: > > On Tue, Nov 21, 2023 at 03:46:43PM +0100, Peter Zijlstra wrote: > > > > > Why is this such a hard question? > > > > Anyway, recapping from IRC: > > > > preemptible, SRCU: > > counter-array based, GP advances by increasing array index > > and waiting for previous index to drop to 0. > > > > notably, a GP can pass while a task is preempted but not within a > > critical section. > > > > SRCU has smp_mb() in the critical sections to improve GP. > > Also: > > preemptible only allows blocking when priority inheritance is > guarantees, which excludes doing I/O, and thus page faults. > Otherwise a long I/O could cause the system to OOM. > > SRCU allows all kind of blocking, as long as the entire SRCU > domain does not mind waiting for a while before readers complete. Well, no. Fundamentally both SRCU and preemptible (and many other flavours) are just a counter-array. The non-blocking for preempt comes from the fact that it is the main global rcu instance and allowing all that would make GPs too rare and cause you memory trouble. But that's not because of how it's implemented, but because of it being the main global instance. > > tasks: > > waits for every task to pass schedule() > > > > ensures that any pieces of text rendered unreachable before, is > > actually unused after. > > > > tasks-rude: > > like tasks, but different? build to handle tracing while rcu-idle, > > even though that was already deemed bad? > > > > tasks-tracing-rcu: > > extention of tasks to have critical-sections ? Should this simply be > > tasks? > > tasks-trace-rcu is meant to allow tasks to block/take a page fault within > the read-side. It is specialized for tracing and has a single domain. It > does not need the smp_mb on the read-side, which makes it lower-overhead > than SRCU. That's what it's meant for, not what it is. Turns out that tasks-tracing is a per-task counter based thing, and as such does not require all tasks to pass through schedule() and does not imply the tasks flavour (nor the tasks-rude) despite the similarity in naming. But now I am again left wondering what the fundamental difference is between a per-task counter and a per-cpu counter. At the end of the day, you still have to wait for the thing to hit 0. So I'm once again confused, ...