From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Paul Adrian Glaubitz Subject: Re: Arches that don't support PREEMPT Date: Tue, 19 Sep 2023 19:58:31 +0200 Message-ID: <64746d98b60f1677cecd26501511f140688801e1.camel@physik.fu-berlin.de> 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> Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" To: Linus Torvalds Cc: Peter Zijlstra , Matthew Wilcox , Thomas Gleixner , 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 Hi Linus! On Tue, 2023-09-19 at 10:25 -0700, 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. Thanks for the detailed explanation. > 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. Great to hear, thank you. And, yes, eventually I would be happy to help get alpha and m68k converted. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913