Received: by 2002:ab2:710b:0:b0:1ef:a325:1205 with SMTP id z11csp705597lql; Mon, 11 Mar 2024 15:12:28 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWVph53btAMzgKDh+0dt4K3XgzXAJ4DnBniTqM5P3MRVsbX9v3m/Rpfoc3C7fjask/WqdSjXpVyMrVO8k2eo3o2xgXmzMHcGC3a1Wrjug== X-Google-Smtp-Source: AGHT+IGaXe6BDhJgm/CQpVbT6WeYoo/rtTRB45qloiyYsFB60+9wba+a+yQ6uci959j3OYzNOfcD X-Received: by 2002:a17:903:2305:b0:1dc:b64:13cd with SMTP id d5-20020a170903230500b001dc0b6413cdmr11905129plh.27.1710195148457; Mon, 11 Mar 2024 15:12:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1710195148; cv=pass; d=google.com; s=arc-20160816; b=TtcAY+Ph1IBSQFtU+z0MRvcTvW/9fLq50eLsXMtCJqjlp+48DubEg9w4gQOLe0R/3M LTIgOF7qS2qUXL5SpiY/xE0jMqkTV17dR7MPNMxq1TRHInyYho7tqZgchQSZFft6QPC2 noKRRwdIcZMSvX840scvT/uIYBQAc0aSBsq+ZHXTfsyJhwOukdp6KkfmgMBv+l/b0jOa 7zijIdsL22nxlyNmPtFGiXGxJQYtOetpJknheLL2fZ+h7Tebm2JJ/qJNpJnB2KZnkaK+ hKEWM5dL0rggCom/uLpqdekCgxE1/b1lx8m/m+muvseSl7eNrkJUrozkDcN3hq6r25tm JOuQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :message-id:date:references:in-reply-to:subject:cc:to:dkim-signature :dkim-signature:from; bh=GL9QhqGRTa3Rvq9zGWZJTH2RJZ51GuDbyPAMx/iVDUE=; fh=BcirAdvw+3o229MEGNl4IuVnmR5KkxN7LEmdPKb1qvY=; b=GdaNZbuUdGnRP2p5epkjt8b1mwdAXGykijcWqK0RAOgSz4cnNVpdo60RrAXHkVLblz IRr/19yIDFhIzHgGaPDqTJQkZHBlYTzsfrF5qNeb8wuiXRzQuzV1lgICBw9ciicdM+Mo GINOnms4sjje/XdSTZykafoNMnHHm784yx1fpuLnb7f85+jQVQAC4XGHKmXVIEn53aAk Mr94Ptbw2fC2mKuz4771j2adz4hXn7uCdMXwfMa1rzpN6a8kr+Pmkax6EiOdGOBoCERd NGf1N8XrNv0hbZ9N22hp0M/OR04czBlM/jeK1+Yy2vsj7MTwzrSZd5kO7CgBNHdMHmYz Ws5w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="Yb/sxm2M"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; arc=pass (i=1 spf=pass spfdomain=linutronix.de dkim=pass dkdomain=linutronix.de dmarc=pass fromdomain=linutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-99596-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-99596-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id u13-20020a170902e5cd00b001dbeba136a2si4703152plf.300.2024.03.11.15.12.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Mar 2024 15:12:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-99596-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="Yb/sxm2M"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; arc=pass (i=1 spf=pass spfdomain=linutronix.de dkim=pass dkdomain=linutronix.de dmarc=pass fromdomain=linutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-99596-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-99596-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 28EAF2815BB for ; Mon, 11 Mar 2024 22:12:28 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 05C0E58113; Mon, 11 Mar 2024 22:12:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Yb/sxm2M"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="XwMUQs7y" Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 550975788F; Mon, 11 Mar 2024 22:12:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710195140; cv=none; b=UJ2VNHSgtL1rVhIp4874VkvLEuS4DWT5mAINDfJI5Qhi9Z0GpwLzHaupmpglTX/aYuBaH248ggVzB4mcSLSEKjQIk/XSX9MZnwVUKhuEBY/vXFiFlov/r5C+3wop3TlF3rI71FpUD+vDQAlHYSyhE0ODBYFKbrWRwWljaggUD9c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710195140; c=relaxed/simple; bh=i+hLVEeFHuIqkZa2pzGvHtLIEKGof99hp8p5L/COMVU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=svIWOnHChulk1/68r5IBWAPfDlO71tir0O7Ik4dWzDjbslOt5WK2NjZYkXzWSXL93LmTblhypHaKcEj2T0y3Wtp88IMOwoYagwZxwU3m9L63Iz9SkTNieKlUzATgMCzk0HRhaNBf/MK2SI4tzD7Zuw6AieaLguzL0rOKP0QVKi0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Yb/sxm2M; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=XwMUQs7y; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1710195135; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GL9QhqGRTa3Rvq9zGWZJTH2RJZ51GuDbyPAMx/iVDUE=; b=Yb/sxm2MWpIpDAKoobTntMEwRDMQqDuAOBUYInGETTXA/7urJex9q4ohJOaYTjDmyzIVno G8vkRrr0Q8mi4UGlsH+o+dRx66q99K5/j7gBsQjVE6WohxjuQvo3rHFpyxYcC9EcTC9Bux O0foUeyhfJ7JD+7Qun0nhV25zy6grFFMwXzL7mcCjOBcXdWO0I/GkYjEwBSgU/db81C1h0 GhvkO7Zb33tiYStEvwbJf9O0rLAxxAUxIEeKKyMGZykWg/cDRxkBGU2Bxerrnf9TTk0qUV 6pKLDm0yW+5B/LDHPjOnLQs743RFcDMwzlXW9Up5TIy7Q1IAozz6lq4GU6X9IQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1710195135; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GL9QhqGRTa3Rvq9zGWZJTH2RJZ51GuDbyPAMx/iVDUE=; b=XwMUQs7ycRbC+VEBSIKrUnFIwx5xMwcOW50wSXzLMB98eaEyOu/QvZ+qWrciIEeIUGICHf ubQWGXfC4rjWu3Dg== To: Ankur Arora , Joel Fernandes Cc: paulmck@kernel.org, Ankur Arora , linux-kernel@vger.kernel.org, peterz@infradead.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jpoimboe@kernel.org, mark.rutland@arm.com, jgross@suse.com, andrew.cooper3@citrix.com, bristot@kernel.org, mathieu.desnoyers@efficios.com, geert@linux-m68k.org, glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com, mattst88@gmail.com, krypton@ulrich-teichert.org, rostedt@goodmis.org, David.Laight@aculab.com, richard@nod.at, mjguzik@gmail.com, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, rcu@vger.kernel.org Subject: Re: [PATCH 15/30] rcu: handle quiescent states for PREEMPT_RCU=n, PREEMPT_COUNT=y In-Reply-To: <877ci8h4pc.fsf@oracle.com> References: <20240213055554.1802415-1-ankur.a.arora@oracle.com> <20240213055554.1802415-16-ankur.a.arora@oracle.com> <20240310100330.GA2705505@joelbox2> <0965542e-80a7-4837-b14e-903c635aa828@paulmck-laptop> <877ci8h4pc.fsf@oracle.com> Date: Mon, 11 Mar 2024 23:12:15 +0100 Message-ID: <87il1spge8.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Mar 11 2024 at 13:51, Ankur Arora wrote: > Joel Fernandes writes: >>> Why not key off of the value of CONFIG_PREEMPT_DYNAMIC? That way, >>> if both CONFIG_PREEMPT_AUTO=y and CONFIG_PREEMPT_DYNAMIC=y, RCU is >>> always preemptible. Then CONFIG_PREEMPT_DYNAMIC=y enables boot-time >>> (and maybe even run-time) switching between preemption flavors, while >>> CONFIG_PREEMPT_AUTO instead enables unconditional preemption of any >>> region of code that has not explicitly disabled preemption (or irq or >>> bh or whatever). > > Currently CONFIG_PREEMPT_DYNAMIC does a few things: > > 1. dynamic selection of preemption model > 2. dynamically toggling explicit preemption points > 3. PREEMPT_RCU=y (though maybe this should be fixed to also > also allow PREEMPT_RCU=n) > > Of these 3, PREEMPT_AUTO only really needs (1). > > Maybe combining gives us the option of switching between the old and the > new models: > preempt=none | voluntary | full | auto-none | auto-voluntary > > Where the last two provide the new auto semantics. But, the mixture > seems too rich. > This just complicates all the CONFIG_PREEMPT_* configurations more than > they were before when the end goal is to actually reduce and simplify > the number of options. > >> That could be done. But currently, these patches disable DYNAMIC if AUTO is >> enabled in the config. I think the reason is the 2 features are incompatible. >> i.e. DYNAMIC wants to override the preemption mode at boot time, where as AUTO >> wants the scheduler to have a say in it using the need-resched LAZY bit. > > Yeah exactly. That's why I originally made PREEMPT_AUTO and > PREEMPT_DYNAMIC exclusive of each other. Rightfully so. The purpose of PREEMPT_AUTO is to get rid of PREEMPT_DYNAMIC and not to proliferate the existance of it. There is no point. All what AUTO wants to provide at configuration time is the default model. So what would DYNAMIC buy what AUTO does not provide trivially with a single sysfs knob which only affects the scheduler where the decisions are made and nothing else? The only extra config knob is PREEMPT_RCU which as we concluded long ago needs to support both no and yes when AUTO is selected up to the point where that model can be switched at boot time too. Seriously, keep this stuff simple and straight forward and keep the real goals in focus: 1) Simplify the preemption model zoo 2) Get rid of the ill defined cond_resched()/might_sleep() hackery All the extra - pardon my french - ivory tower wankery on top is not helpful at all. We can debate this forever on a theoretical base and never get anywhere and anything done. Please focus on getting the base mechanics in place with the required fixes for the fallout for preemptible and non-preemtible RCU (selected at compile time) and work it out from there. Perfect it the enemy of good. Especially when nobody can come up with a perfect definition what 'perfect' actually means. Thanks, tglx