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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9ACBC4167B for ; Tue, 28 Nov 2023 10:53:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EB3F6B024D; Tue, 28 Nov 2023 05:53:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2742E6B024F; Tue, 28 Nov 2023 05:53:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1157A6B0288; Tue, 28 Nov 2023 05:53:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id F31E66B024D for ; Tue, 28 Nov 2023 05:53:24 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CBBF61A0173 for ; Tue, 28 Nov 2023 10:53:24 +0000 (UTC) X-FDA: 81507051528.06.84A33B0 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf03.hostedemail.com (Postfix) with ESMTP id 0AA0620020 for ; Tue, 28 Nov 2023 10:53:22 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=fHlZqCBd; dkim=pass header.d=linutronix.de header.s=2020e header.b=BfRS4p2O; spf=pass (imf03.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701168803; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:dkim-signature; bh=b+nmSGDUEGGbpS4OWXh0DOTLqhAcww6OfuIQLAIqmSk=; b=s3Hu9QZRtzvES3CLRWFozeqQQMH5KtRrrhftTCbMno3FGy4kR/o9a1MnuJm+hkbptUhTqu DDNIbOUFtCCoASuNcok4QdxMNPMMH/ItZmCJo6N39uFzl4K410uukL+8lK0olRs3gfc7Eg LCpJQNYyqbLEUjZD9etkM2qf/VmCyeA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701168803; a=rsa-sha256; cv=none; b=kVhb20GwcilY71zr9fiauh2fupcsescEDv06h6Yv3RP0u1sr86wm4wlLxku1beO87pQqbt FfWtIRfMTyNz1kCdRGy0ffHxLBV2zyXsMO9pcuLvw9q3iy4R6U2Y8AAcZb0M7Fq7869+1x sv0QAIXksUDtKMpmJBAxAQZax28ve/M= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=fHlZqCBd; dkim=pass header.d=linutronix.de header.s=2020e header.b=BfRS4p2O; spf=pass (imf03.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1701168800; 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; bh=b+nmSGDUEGGbpS4OWXh0DOTLqhAcww6OfuIQLAIqmSk=; b=fHlZqCBdJXpCeUuNADw2Y84vgaVgAH+Z4kKjzUmk+9zW1l9XJjgLVK4ovgOTTGMQxwekNI FpS8iuVbWQbbYmjvLUdEMuGklceDgIwQg7L/nG6+yKtJ9PibTiuWFb8LCdgNAR1YyG0Iql 4S8gbjpOB+ke2l21VnQkFQ7qWiZrlINghV/DZsoTNFh/EIkYi+djv4Ry1n+F0EPebK0OMi cLpoaNE/tuzjgs0SbQGT7t3a4GmdL9QLo84KJESv89zpQQnYB5czrK+rB8OFQeqVCUqoyW m2qlXuUzihqtNqLp2eUfWEdOUAjvygGMGs6C5m/SbZDNmyYwUh3ZSIGTvv22bQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1701168800; 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; bh=b+nmSGDUEGGbpS4OWXh0DOTLqhAcww6OfuIQLAIqmSk=; b=BfRS4p2OwGfCsN9elxynun7sb8wovaOBqBu8g8+QVG8f+qwRNSKESsGNnr9IJqr8twaRc1 tubk7Mo6hW8tMNAA== To: paulmck@kernel.org, Steven Rostedt Cc: Ankur Arora , linux-kernel@vger.kernel.org, peterz@infradead.org, torvalds@linux-foundation.org, linux-mm@kvack.org, x86@kernel.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, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, mingo@kernel.org, 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, David.Laight@aculab.com, richard@nod.at, mjguzik@gmail.com, Simon Horman , Julian Anastasov , Alexei Starovoitov , Daniel Borkmann Subject: Re: [RFC PATCH 47/86] rcu: select PREEMPT_RCU if PREEMPT In-Reply-To: Date: Tue, 28 Nov 2023 11:53:19 +0100 Message-ID: <87wmu2ywrk.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: o1dnhdah7wjc6xmds914wsrj5kibm7h7 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 0AA0620020 X-Rspam-User: X-HE-Tag: 1701168802-36167 X-HE-Meta: U2FsdGVkX1+EjUzHJ0TB9F1SF5JJVSjCXCsPYYmZ3v9M/IRHo1rCQnborIhvEHCmbVuyzWvv0W1wWgcpZpVpfZA90QGIguEeNcOQps9mLeTmu2XbFBxrP5nG3G4f9tQTj+eIc8PybOINogY4VtkRfYTtLTzgku7f5hFu3l0TLiv9MrrKyuAkEy76l26Eclkra8VYwlhwNPsPWtgouaTvUWb+iFpD8Bi9bTC4E5ptgUQtXIZaVF14J7EgqFB3Be77v7OvVQTd7YA4hiagGg+qbVPOkaRbJxg0xDOgyvrLlZujTkEG7A3Ql9QLmF15gW/Y6ku+5CSNq1twYNqiqYelh5YwwnUOzIyt0SQykkfRP+VRpMwoWl0FH0XjZKSyCNj44QCUFLKAk15SNVPikk4IVw8UBxRqfsbWoE2RNR1YLwUzUm+fcEd9b1ff0Tl21PPgPrIPIuCkma54J2Rdy5HleMLAyFZb3K/hKs24kx0HlHczIBGdYrzNpJzRPBHNaoahQMB8Pd2oYsfnZwP9gWUTPSp8G1mnafMzgMeEq00gB4RBpQagFQYAoSS+djmR4Eqm6JDxnpZmSByeaHJWS4i265OlYksMO22Vu/IbMvqp/epvD2CDs5AqOqYxdV95JjAcgW0L5l3/FC/3lvWLDpwvD75WA/Vt7G4H3D24ODnmE0nl2RQljV3MEP8DAedo6E7qjy5iOiqpLyJB4hwcKIZNRhV+ZRJvLliLb8dTJDn7aTWrfM5tWxj2Z6dJvJ342BFVbAlH/fXnr8pthwJG3rh2QmOMrDOZ3JGqe0FfCL0cvtfoKz8+buJg0du67nDfhfF3WX3ZajHGzntJsgMnhzrQH9JLw/QJ81KC9oSC6kJveCbLldUQtsQnlzQAVIdKOa253wPej7dJzgSlf/x6mgGm9DdTy6xb1TDT40vcPgoiUyXqNdeIfwuivDq7iBTyc6lYG9Q1m7E4k5PAzsR53c5 8DkkR4Jq LCut1V9kfIfA4/XXxLoIKHGrsJvdukYa/fOySZRN+mHJR2yoQpPH3FCo4fSjRcdFGtqVRpGOYY168WcGNp/WMRmS1SSGX57KtvNxsf+znSexOkbHW7oLhXrepTMW3FJcAGHihH6VBrxOtRrg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Paul! On Tue, Nov 21 2023 at 07:19, Paul E. McKenney wrote: > On Tue, Nov 21, 2023 at 10:00:59AM -0500, Steven Rostedt wrote: >> Right now, the use of cond_resched() is basically a whack-a-mole game where >> we need to whack all the mole loops with the cond_resched() hammer. As >> Thomas said, this is backwards. It makes more sense to just not preempt in >> areas that can cause pain (like holding a mutex or in an RCU critical >> section), but still have the general kernel be fully preemptable. > > Which is quite true, but that whack-a-mole game can be ended without > getting rid of build-time selection of the preemption model. Also, > that whack-a-mole game can be ended without eliminating all calls to > cond_resched(). Which calls to cond_resched() should not be eliminated? They all suck and keeping some of them is just counterproductive as again people will sprinkle them all over the place for the very wrong reasons. > Additionally, if the end goal is to be fully preemptible as in eventually > eliminating lazy preemption, you have a lot more convincing to do. That's absolutely not the case. Even RT uses the lazy mode to prevent overeager preemption for non RT tasks. The whole point of the exercise is to keep the kernel always fully preemptible, but only enforce the immediate preemption at the next possible preemption point when necessary. The decision when it is necessary is made by the scheduler and not delegated to the whim of cond/might_resched() placement. That is serving both worlds best IMO: 1) LAZY preemption prevents the negative side effects of overeager preemption, aka. lock contention and pointless context switching. The whole thing behaves like a NONE kernel unless there are real-time tasks or a task did not comply to the lazy request within a given time. 2) It does not prevent the scheduler from making decisions to preempt at the next possible preemption point in order to get some important computation on the CPU. A NONE kernel sucks vs. any sporadic [real-time] task. Just run NONE and watch the latencies. The latencies are determined by the interrupted context, the placement of the cond_resched() call and the length of the loop which is running. People have complained about that and the only way out for them is to switch to VOLUNTARY or FULL preemption and thereby paying the price for overeager preemption. A price which you don't want to pay for good reasons but at the same time you care about latencies in some aspects and the only answer you have for that is cond_resched() or similar which is not an answer at all. 3) Looking at the initial problem Ankur was trying to solve there is absolutely no acceptable solution to solve that unless you think that the semantically invers 'allow_preempt()/disallow_preempt()' is anywhere near acceptable. Thanks, tglx