Messages in this thread | | | From | Arnd Bergmann <> | Date | Mon, 9 Nov 2020 20:10:29 +0100 | Subject | Re: [PATCH 2/3] arm: introduce IRQ stacks |
| |
On Mon, Nov 9, 2020 at 3:45 PM Tony Lindgren <tony@atomide.com> 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 ;-)
I suppose the existence of omap2plus_defconfig and imx_v6_v7_defconfig means it does at least get tested regularly.
Arnd
| |