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 X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D65EC55ABD for ; Tue, 10 Nov 2020 09:19:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DA9E120870 for ; Tue, 10 Nov 2020 09:19:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728632AbgKJJTL (ORCPT ); Tue, 10 Nov 2020 04:19:11 -0500 Received: from muru.com ([72.249.23.125]:47586 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726213AbgKJJTL (ORCPT ); Tue, 10 Nov 2020 04:19:11 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 4178A80BA; Tue, 10 Nov 2020 09:19:13 +0000 (UTC) Date: Tue, 10 Nov 2020 11:19:04 +0200 From: Tony Lindgren To: Arnd Bergmann Cc: Russell King - ARM Linux admin , v.narang@samsung.com, a.sahrawat@samsung.com, Marc Zyngier , Sebastian Andrzej Siewior , Vincent Whitchurch , Nick Desaulniers , "linux-kernel@vger.kernel.org" , Nathan Huckleberry , Jian Cai , Thomas Gleixner , Dmitry Safonov <0x7f454c46@gmail.com>, Maninder Singh , Andrew Morton , Will Deacon , Valentin Schneider , Linux ARM Subject: Re: [PATCH 2/3] arm: introduce IRQ stacks Message-ID: <20201110091904.GC26857@atomide.com> References: <1602141333-17822-1-git-send-email-maninder1.s@samsung.com> <1602141333-17822-3-git-send-email-maninder1.s@samsung.com> <20201021124542.GL1551@shell.armlinux.org.uk> <20201021125740.GM1551@shell.armlinux.org.uk> <20201109144549.GA26857@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Arnd Bergmann [201109 19:10]: > On Mon, Nov 9, 2020 at 3:45 PM Tony Lindgren wrote: > > > > > > As discussed on IRC, I think it can still be done in one of these > > > ways, though admittedly none of them are perfect: > > > > > > a) add runtime patching for __my_cpu_offset() when > > > CONFIG_SMP_ON_UP is set. This adds complexity but avoids the > > > fallback for for SMP&&CPU_V6. It possibly also speeds up > > > running on single-cpu systems if the TPIDRPRW access adds > > > any measurable runtime overhead compared to patching it out. > > > > Out of these options a) sounds best to me. > > Ok. Maninder, would you like to give implementing this a try? > > > > b) If irq stacks are left as a compile-time option, that could be > > > made conditional on "!(SMP&&CPU_V6)". Presumably very > > > few people still run kernels built that way any more. The only > > > supported platforms are i.MX3, OMAP2 and Realview-eb, all of > > > which are fairly uncommon these days and would usually > > > run v6-only non-SMP kernels. > > > > This has been working just fine for years though. In general, > > removing the conditional compile ifdefferey has made things quite > > a bit easier for us, so let's continue on that. > > > > > c) If we decide that we no longer care about that configuration > > > at all, we could decide to just make SMP depend on !CPU_V6, > > > and possibly kill off the entire SMP_ON_UP patching logic. > > > I suspect we still want to keep SMP_ON_UP for performance > > > reasons, but I don't know how significant they are to start with. > > > > And this too has been working just fine for years :) > > I know it works, my point was that I'm not sure anyone cares > any more ;-) Well for example whatever Linux running ARMv6 LTE modems out there might need to be supported for quite some time. Not sure how many of them are able to update kernels though. Certainly network security related issues would be a good reason to update the kernels. > I suppose the existence of omap2plus_defconfig and > imx_v6_v7_defconfig means it does at least get tested > regularly. Yes. I probably would just stop any random ARMv6 related testing if it it needs a custom .config. Regards, Tony