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 90E83CE79A9 for ; Tue, 19 Sep 2023 18:31:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C49D06B00AA; Tue, 19 Sep 2023 14:31:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF9136B00AC; Tue, 19 Sep 2023 14:31:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9A316B00AF; Tue, 19 Sep 2023 14:31:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 941276B00AA for ; Tue, 19 Sep 2023 14:31:55 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 647FB1A0E74 for ; Tue, 19 Sep 2023 18:31:55 +0000 (UTC) X-FDA: 81254190990.11.5302C33 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 55AE040007 for ; Tue, 19 Sep 2023 18:31:53 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=xXqJqYUZ; dkim=pass header.d=linutronix.de header.s=2020e header.b="HSw+FE/2"; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf07.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695148313; 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:references:dkim-signature; bh=mKyOmmSSJD2Ws4VR+XqPS/XNP5VPNOwNw6yDdf2ZDQU=; b=7G0hyQdbFTrje2J9zZolWbqsoafHoW3rTAH/d/hOm673FvO8A/SISLjfG/dydYgdu6lW5g XcUHvEVSjCp7ldjYcuWf/4bNMCYEUSApZ4i+aZVAnAFIEcXZ03ZNY8GFvIEqpT1C+uaooR RCiM5AcxFj8EmwepN9BYbIM6Prwv0ms= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=xXqJqYUZ; dkim=pass header.d=linutronix.de header.s=2020e header.b="HSw+FE/2"; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf07.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695148313; a=rsa-sha256; cv=none; b=O7A6HVNcZTKsUwhouz+fUB+D/h9PNeP1ODBGLa44TYILjZaccizl0TGn0pULoDJfHyOrmH E6/ENg5v9KY59WU2ABZ1yqtAdpEXEUXNUt3IU/fwMN5Xd+u0bKV2F4lN8qTJ2sXJiL5lN3 4bBH1P/t5tstH9tStAcazSLIHjeIEJ0= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1695148311; 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=mKyOmmSSJD2Ws4VR+XqPS/XNP5VPNOwNw6yDdf2ZDQU=; b=xXqJqYUZla9VpgC4S4ShTGkMIL3gkkhNvGjlWhi5L1gkuz5icUdocjTZfEjeUV9x1XfF1d 9gCf9onnbE0u4V9GNNs47U9xjPBMw2DWytTSoQsodttKIzqkL+7HlaYEWW4FSVqwFkxP9b m3N7cld1jgwk+v3jf2F2vowyOYzbp0oeTYfBdyMg3skppXJK7mZs9rhgY8B0yUaEjzj5rv eNPjV+ty7EkQisVX1wCgp5HdgxQTcki84SeKDSqMlKMRQ4Dwk5yJNMqTIIkjzdPuUEmZXw ZLXZiD6XCNIDxdM95XJgYydUDvKFSGuDWDp3q+ZqWzDj1uSibW0RuXplJpLfmA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1695148311; 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=mKyOmmSSJD2Ws4VR+XqPS/XNP5VPNOwNw6yDdf2ZDQU=; b=HSw+FE/2ECBsn8P+jBW//lrHd8c9W9Bxp5rJpQcF0U/qlJOFxqfRtQIDeqJGdvK2cG7ELT v2DdyOFXFBXeLSDg== To: Linus Torvalds , John Paul Adrian Glaubitz Cc: Peter Zijlstra , Matthew Wilcox , Ankur Arora , linux-kernel@vger.kernel.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, mgorman@suse.de, rostedt@goodmis.org, 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, Geert Uytterhoeven , linux-m68k@lists.linux-m68k.org, Richard Weinberger , Anton Ivanov , Johannes Berg , linux-um@lists.infradead.org, Brian Cain , linux-hexagon@vger.kernel.org, Richard Henderson , Ivan Kokshaysky , Matt Turner , linux-alpha@vger.kernel.org Subject: Re: Arches that don't support PREEMPT In-Reply-To: References: <87zg1u1h5t.fsf@oracle.com> <20230911150410.GC9098@noisy.programming.kicks-ass.net> <87h6o01w1a.fsf@oracle.com> <20230912082606.GB35261@noisy.programming.kicks-ass.net> <87cyyfxd4k.ffs@tglx> <87led2wdj0.ffs@tglx> <0e69f7df80dc5878071deb0d80938138d19de1d1.camel@physik.fu-berlin.de> <20230919134218.GA39281@noisy.programming.kicks-ass.net> Date: Tue, 19 Sep 2023 20:31:50 +0200 Message-ID: <87pm2eui95.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 55AE040007 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: c1p8qii5qok69xyxxypurz6rijhyxdm1 X-HE-Tag: 1695148313-22735 X-HE-Meta: U2FsdGVkX18QkTdljeUIng1VK0I08y7Se8vBdkY9ePXK1KikQUPC/pFu+6CY1xJRIxrkObRsuIWAIlky+/dPRM31t1oeuZ5D1l+s3FYeK9MCHGmVOFvTtjox1F44vBQ6S4HWFTAHuOiABhMzMQzJZzCfh0OLnhg4JI+mFHtLDLYgXKvUt5M+ZWhm7xAuGAWuboMqP6yeIQY+g5xdhPJXnrSd4Iuzq5HcWsENcEXfbpv7LTCvCOChq6aPrdDCwtLBjJwlSoEta3IlaGdw5rfET6reibYF8uFsMf3+DtWS0EIyc2YXeJ6ev/GppwVOnWgUmZxePGoqNOH+x5JnMki64j+myq30JISvz0lUr70pzpPTReSZF+IQ0dO9RuYeiQ2vHwbzs0KlMKLC01i4sqONG3fv8w6ydLEPw8BTmhbBRycVcZwYGBdY0jKz9udkETzMpP/wOYkA4oSjXdkTtzClhQ+9QtVzzmDG1OJ8Zkn/5y6vq4PUes6uj0bGd5/tgWE82z7SxZE9TjLoGet2cIGN0wBDtrvXlntnSq0YgmZSoM/oMgWtstRK8wAPozWFIO5wFsR1/LkEDZghhZR9MOS/Ic2QVJdC2QLZd5iNg+0j7svQWL5zCGlFE6275N9ApuduM13gNVO+CFmFXZcHrYMazvaTfTUxqNtofUlMjCAKOKGkNkQ68sJZyExmMcIituY6ZpdtuGMqJwFDDlnCy9+kfXQiPUNSXZVqoQlurbR3tkIt5ZnBjVMsHO19xhAQz+vwFjpNdkHe0U6MukD3JRePEaIYXStvwWbTsg1BzYQgc1QNJxqLCenWqzhCcW657iVEEEKdzTMGmF+hKnEBQ2oyrLT4qajk0zv/vb+Zq/qcUMB78irHc9M9rBzsM34EHRwF+mgBJp5IrTn11Ml7C93Xx+u1dJKkdH9H1NI65J/lPNbZ5UwoSGbVdA0jl4LRW30YXWL1tNXI3hVKD5jxPt5 ot5BIlNk XoUYakGLIs3Oh1EdRELba9bEcfGh9d6Jj1T1nGS5NOvUflw4= 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: On Tue, Sep 19 2023 at 10:25, Linus Torvalds wrote: > On Tue, 19 Sept 2023 at 06:48, John Paul Adrian Glaubitz > wrote: >> >> As Geert poined out, I'm not seeing anything particular problematic with the >> architectures lacking CONFIG_PREEMPT at the moment. This seems to be more >> something about organizing KConfig files. > > It can definitely be problematic. > > Not the Kconfig file part, and not the preempt count part itself. > > But the fact that it has never been used and tested means that there > might be tons of "this architecture code knows it's not preemptible, > because this architecture doesn't support preemption". > > So you may have basic architecture code that simply doesn't have the > "preempt_disable()/enable()" pairs that it needs. > > PeterZ mentioned the generic entry code, which does this for the entry > path. But it actually goes much deeper: just do a > > git grep preempt_disable arch/x86/kernel > > and then do the same for some other architectures. > > Looking at alpha, for example, there *are* hits for it, so at least > some of the code there clearly *tries* to do it. But does it cover all > the required parts? If it's never been tested, I'd be surprised if > it's all just ready to go. > > I do think we'd need to basically continue to support ARCH_NO_PREEMPT > - and such architectures migth end up with the worst-cast latencies of > only scheduling at return to user space. The only thing these architectures should gain is the preempt counter itself, but yes the extra preemption points are not mandatory to have, i.e. we simply do not enable them for the nostalgia club. The removal of cond_resched() might cause latencies, but then I doubt that these museus pieces are used for real work :) Thanks, tglx