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.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 30D48C5517A for ; Tue, 10 Nov 2020 09:20:26 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A32BD20780 for ; Tue, 10 Nov 2020 09:20:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="xH17zsj2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A32BD20780 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomide.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oSFa85hLrRo4XDiRPMttmz0jA1Hob6MQB/AZuJBinH0=; b=xH17zsj2+K2LrVddE3oBOUZEc 5yLyGOx01Y+3+aJfN7eUKK69B0icQIWdoSDCR09rnFUARB2QMTWbp8y1iw1wPXiFG+iv5AA/3KyfZ m5bLBubzWfTBHKJrLGnn9qwwQnEZ86jaqXC6oCQvPgyuXXHJb5Z5/W8BnO4EuCWmhbAjP5fGdz6RW HqzXxo9HqylT44YJezoR8im2QIGVJ/qkHA4ur/T76mfwrKnxFUnq3W1aXujKswlkWQ/IKjUB5f4Da Xp5gg/lQ2MjGU/3HCHCSJcEoYjdgP9aVLnQWgP13REywWMZ+S/85i9ZtoDkM3czi43BukKFUiVDwp /I2VxaULg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcPo5-0002Xr-2q; Tue, 10 Nov 2020 09:19:17 +0000 Received: from muru.com ([72.249.23.125]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcPo1-0002Wm-VV for linux-arm-kernel@lists.infradead.org; Tue, 10 Nov 2020 09:19:14 +0000 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 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201110_041914_119398_F4351CB3 X-CRM114-Status: GOOD ( 30.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: v.narang@samsung.com, a.sahrawat@samsung.com, Andrew Morton , Marc Zyngier , Sebastian Andrzej Siewior , Vincent Whitchurch , Nick Desaulniers , Russell King - ARM Linux admin , "linux-kernel@vger.kernel.org" , Valentin Schneider , Dmitry Safonov <0x7f454c46@gmail.com>, Maninder Singh , Thomas Gleixner , Nathan Huckleberry , Will Deacon , Jian Cai , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel