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 C3F70CD5BC7 for ; Tue, 19 Sep 2023 14:17:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E8FE6B0544; Tue, 19 Sep 2023 10:17:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 598F06B0545; Tue, 19 Sep 2023 10:17:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 461926B0546; Tue, 19 Sep 2023 10:17:09 -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 399B96B0544 for ; Tue, 19 Sep 2023 10:17:09 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D78FA160D42 for ; Tue, 19 Sep 2023 14:17:08 +0000 (UTC) X-FDA: 81253548936.21.5580D81 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf30.hostedemail.com (Postfix) with ESMTP id BA7EE8002E for ; Tue, 19 Sep 2023 14:17:06 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=BOxMpPsV; dkim=pass header.d=linutronix.de header.s=2020e header.b=nRpx4S8f; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf30.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=1695133027; 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=AzWx00LzOrWB97CWuV/YA9TmYjDj3ZDIMkfBUMc4vK4=; b=HpEIFEuvJ+k7B8f98TrGLozh9ISt+WzIcnOQpiWn1E4ll9v1n9TeqYVllEr+gFa2nKQsqe fBzu1TrqlRpSPQJmacqBfxXvui89DuV4WiEuzW3Yf/XRUJ7aoHPDEJkIKfWCJxMa+jEQc4 tjmm49HtgrbQrOTbYExgJHetiBCPqXY= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=BOxMpPsV; dkim=pass header.d=linutronix.de header.s=2020e header.b=nRpx4S8f; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf30.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=1695133027; a=rsa-sha256; cv=none; b=xyrABY7YDcDSvr44RVgqbz1nVk4JuZg9bORr/0XFYPUEsEGUTpeF4jm30RJt3e920fwOsY 7HIQDHEiJ9CUjvN/4xlUpVd24Fx0Z/UUn60EmyWopZ+M9mC67o1pu/sd68dYnkKXoMq3fF MJv8KA0bf6GCZnhZyNKc9/FAoSls60w= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1695133024; 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=AzWx00LzOrWB97CWuV/YA9TmYjDj3ZDIMkfBUMc4vK4=; b=BOxMpPsViTe4eAtpu1ohDtFuIpN7IjvrZhvOBsd6347EBpK1i33XuSFab8AL0lweo+PFy8 3iOGDMIC+Hvv+hkN5eCfmcGqjfheYxtMZOzKC2dGwAvwVE43AtzVXjipdaNuZPnRPbknwE NhtRbmiYrJlKh0tGITD5wAlrwn4Xa6bmHo3iBcler3nO26HcQQl1xzJ/mp0JZif/nQtWlF dBjwcMDZfWh/3oIWHNKiGV3t+tWujITFdQ7bz0UDDF95w9VGLx6XyR7FCO5Coye1/DEUi6 rLum0uGnFlDWQ9t4rol0rAMiYlovZXwlD2eyyMvvFhw0zpX9gnqC1yMp/YlV2g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1695133024; 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=AzWx00LzOrWB97CWuV/YA9TmYjDj3ZDIMkfBUMc4vK4=; b=nRpx4S8fWZgScRYmAhyhfVuD4eX5xNxfXOTycjWAjLwMsE2Xlh4NbkKZ/6cMTKcYmUdKVK LXdA7Tw5o0myYtBA== To: John Paul Adrian Glaubitz , Peter Zijlstra Cc: Matthew Wilcox , Linus Torvalds , 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 16:17:04 +0200 Message-ID: <877comw8m7.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Stat-Signature: np6g4eexyx7rg87wnpo4nkxywn9xmpkd X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BA7EE8002E X-HE-Tag: 1695133026-611010 X-HE-Meta: U2FsdGVkX1/6inyK8h8Y9BKz1KvFBL9c2BHCrwHbQs07C+U7pl4o7rQoS73ZAI9+N/grfFFEh5bccJAVaHyzPY+r9FHXozYyVDoC/vr1I7Cpk3WfeYiRywxHHp7OazWilG/zhrNTj/WTukZ8meGb8vXGlVwbarZ4Yh3yIzL30Ctk0smusqLpm/voI0a5KIUHfcwp/zGEddIE1cHQYOagdJL/jh2v/PveWh1yvDEJZJU6P5tf/IqTtv/EcN4cE2oCo5O8XVEhr0AyQy0UFxRRjlLCpshKZtoy7GIXinFdYLkAVBE6UiiyE7jmACiIJ6EQDIRw6QtOpbBlIcLrS3+c6Sh9MVO+ayYzAfEes1ZpkSzn1atuEgm1jmcCF8y5x7nC40w8wb2/ootia5X139I3FBtETjMHxTRGRSJ7zCBIDj88/c7MyB94EPElf/dIfckTlANs0/CHVMXcOvK5oPNcb5Z8Er6h/6SyZOVp1qCfv5sGs1sJnyECV3wnyT2u/AN/AhgJTcqbE3sXi8FaPvNFaqdYkWBvLcfOiZX7qUiyk9ni9nBTZVL8NlcVjPsAj0rIwFp1+FN6jXNF79eiKlbQYr26E6j6zNGrQstIuxT/lHtHdKFlVIjLfsgwM6fwzQALwXX0eTCcLVlVjOfsQZsdkiCA7DN9TXNHsEqvBnE1Ub0SUtVWNqemvPUrvNc71IpGnOSOmXzIOQm7vYphxbPzcLy2pBVGbNPuhNZLJHZMKsoTwp+jGvN3Ru8pJPVzXG0UIuCavtMMephOFAyE/ELfauls0mzSF1BnFo0V5qYxPX4jnXNNnHljoWgrRANFazHGyBmAba0lg0pWGVartDTl4fp2S2vZn9R38sMMdi1rKsvuA2T5a2KLbYdb0mNHk7Zl5oba68sQyXgzKVwsv5yzyOUkXJ1F3E9ufU9HxjEYMcR9OKQgsCMNGmw+n+xc5aGjE256Ep+X0jzG/sSqcnZ RmUiY/uR zX1RlWG/Xn2tha6FNR6IS7CMtBUCawe9dao6YqciUf93/RCA= 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 15:48, John Paul Adrian Glaubitz wrote: > On Tue, 2023-09-19 at 15:42 +0200, Peter Zijlstra wrote: >> > The agreement to kill off ia64 wasn't an invitation to kill off other stuff >> > that people are still working on! Can we please not do this? >> >> If you're working on one of them, then surely it's a simple matter of >> working on adding CONFIG_PREEMPT support :-) > > 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. > > I find it a bit unfair that maintainers of architectures that have huge companies > behind them use their manpower to urge less popular architectures for removal just > because they don't have 150 people working on the port so they can keep up with > design changes quickly. I don't urge for removal. I just noticed that these four architectures lack PREEMPT support. The only thing which is missing is the actual preemption point in the return to kernel code path. But otherwise it should just work, which I obviously can't confirm :) Even without that preemption point it should build and boot. There might be some minor latency issues when that preemption point is not there, but adding it is not rocket science either. It's probably about 10 lines of ASM code, if at all. Though not adding that might cause a blocking issue for the rework of the whole preemption logic in order to remove the sprinkled around cond_resched() muck or force us to maintain some nasty workaround just for the benefit of a few stranglers. So I can make the same argument the other way around, that it's unjustified that some architectures which are just supported for nostalgia throw roadblocks into kernel developemnt. If my ALPHA foo wouldn't be very close to zero, I'd write that ASM hack myself, but that's going to cost more of my and your time than it's worth the trouble, Hmm. I could delegate that to Linus, he might still remember :) Thanks, tglx