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 61256CE79A9 for ; Tue, 19 Sep 2023 17:34:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232042AbjISReK (ORCPT ); Tue, 19 Sep 2023 13:34:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232038AbjISReG (ORCPT ); Tue, 19 Sep 2023 13:34:06 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B82CC6; Tue, 19 Sep 2023 10:34:00 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1695144838; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Q5XoD2rR1P7xfyZ4vS5WECNooPW5RHsWgoNmWq+2hMo=; b=UJuEQFI+fVdHak0lB8fNvstykL9kpTeNJD+gjygB9iKFIoN1n7qL5fa8q1zibRy2IPQ6Qe NyukDnTgIGP7wS4FzYHD5OGCHF62//LTFHZZ8yP9IQToCNuSqQ1GH+7YaaGPaBI/CX6Z8V 8Vzbr2wmmB33ZJMWTR30JR513dx/C+zEch08e6QwhmiWdN2hx57bNIhu4sFxTiAQXh1Xn1 G7Uqydw7R+LQiZU2Twrng6XRlmrm/mXOIsAXYOgo5eW8rhYLGVEvA9DBjj6ZiIG4ffl66+ NOsgtS0rfYpuBXj0rw8P+dSYdXzP2sFea+0Hqq+BkBT6knNGfVPF/+sEjn1HEA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1695144838; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Q5XoD2rR1P7xfyZ4vS5WECNooPW5RHsWgoNmWq+2hMo=; b=FC96a8Jt867By47LPHSnv602OXYh1+2tD7k+Vqqy6gx0P6BeLouKDBbYI0Ubu/ALeBPwSe ofg019sZqzn6gQAQ== To: Anton Ivanov , Richard Weinberger Cc: Peter Zijlstra , John Paul Adrian Glaubitz , Matthew Wilcox , torvalds , Ankur Arora , linux-kernel , linux-mm , x86 , Andrew Morton , Andy Lutomirski , bp , dave hansen , hpa , mingo , juri lelli , vincent guittot , mgorman@suse.de, Steven Rostedt , jon grimm , bharata@amd.com, raghavendra kt , boris ostrovsky , konrad wilk , jgross , andrew cooper3 , Geert Uytterhoeven , linux-m68k , Johannes Berg , linux-um , Brian Cain , linux-hexagon@vger.kernel.org, Richard Henderson , Ivan Kokshaysky , Matt Turner , linux-alpha Subject: Re: Arches that don't support PREEMPT In-Reply-To: References: <87zg1u1h5t.fsf@oracle.com> <87led2wdj0.ffs@tglx> <0e69f7df80dc5878071deb0d80938138d19de1d1.camel@physik.fu-berlin.de> <20230919134218.GA39281@noisy.programming.kicks-ass.net> <87y1h2ur98.ffs@tglx> <9a5c0856-d542-9912-7494-53d7fe4538a3@cambridgegreys.com> <551475267.58816.1695140566849.JavaMail.zimbra@nod.at> Date: Tue, 19 Sep 2023 19:33:57 +0200 Message-ID: <87v8c6ukxm.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 19 2023 at 17:41, Anton Ivanov wrote: > On 19/09/2023 17:22, Richard Weinberger wrote: >> ----- Urspr=C3=BCngliche Mail ----- >>> Von: "anton ivanov" >>> It's been a while. I remember that I dropped it at the time, but do not= remember >>> the full details. >>> >>> There was some stuff related to FP state and a few other issues I ran i= nto while >>> rewriting the interrupt controller. Some of it may be resolved by now a= s we are >>> using host cpu flags, etc. >>=20 >> I remember also having a hacky but working version almost 10 years ago. >> It was horrible slow because of the extra scheduler rounds. Which can be completely avoided as the proposed change will have the preemption points, but they are only utilized when preempt FULL is enabled (at boot or runtime). So the behaviour can still be like preempt NONE, but with a twist to get rid of the cond_resched()/might_resched() and other heuristic approaches to prevent starvation by long running functions. That twist needs the preemption points. See https://lore.kernel.org/lkml/87cyyfxd4k.ffs@tglx >> But yes, if PREEMPT will be a must-have feature we'll have to try again. > > We will need proper fpu primitives for starters that's for > sure. fpu_star/end in UML are presently NOOP. > > Some of the default spinlocks and other stuff which we pick up from > generic may need to change as well. > > This is off the top of my head and something which we can fix straight > away. I will send some patches to the mailing list tomorrow or on Thu. I think it does not have to be perfect. UM is far from perfect in mimicing a real kernel. The main point is that it provides the preempt counter in the first place and some minimal amount of preemption points aside of those which come with the preempt_enable() machinery for free. Thanks, tglx