On 11 Mar 16, Nicolas Pitre wrote: > On Fri, 11 Mar 2011, Amit Kucheria wrote: > > > On Fri, Mar 11, 2011 at 12:32 PM, Dave Martin <dave.mar...@linaro.org> > > wrote: > > > On Wed, Mar 9, 2011 at 9:13 AM, Andy Green <a...@warmcat.com> wrote: > > >> On 03/09/2011 09:04 AM, Somebody in the thread at some point said: > > >> > > >>>> I take it this magic of SMP or not is hidden in this config layering > > >>>> scheme > > >>>> you mentioned and it isn't really using the same config for say > > >>>> igep0020 > > >>>> and > > >>> > > >>> No, it is in the black depths of ARM assembly and TBH, it is voodoo to > > >>> me. Nothing to do with kernel config as such. The SMP kernel, at > > >>> runtime, (binary) patches itself to convert locking primitives to > > >>> no-ops in the UP case. Or something to the effect. > > >> > > >> Hum my IGEP0020 config here has CONFIG_BROKEN_ON_SMP=y set so I guess > > >> this > > >> is to do with what you mentioned. > > >> > > >>>> Panda. In any event, there's a performance tradeoff running SMP kernel > > >>>> on > > >>>> uniprocessor to consider too. > > >>> > > >>> Apparently, with this one-time patching (per boot) there isn't such a > > >>> tradeoff. > > >> > > >> OK thanks for the explanation. > > > > > > SMP-on-UP appears to be fully working nowadays. We currently don't > > > build a single SMP kernel for omap4 and omap3, but I've been playing > > > with that and it's been shown to work. Does anyone know whether we're > > > planning to move to a single OMAP kernel? Has anyone measured the > > > performance delta? > > > > > > In principle, we could make this move; but there could be issues I'm > > > not aware of. > > > > > > Note that the SMP-on-UP support is fairly minimal -- only those things > > > which literally will fail on UP are patched out. > > > > Do you have a pointer to the patches that enabled this support? SHA > > ids are fine. I'm curious what the runtime patching voodoo looks like. > > commit f00ec48fadf5e37e7889f14cff900aa70d18b644 > ARM: Allow SMP kernels to boot on UP systems > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f00ec48fad > > We now have a similar clever trick for a runtime determined PHYS_OFFSET: > > commit f47ecb85ba9c67cf6f6eba39c19cc528f783f5e7 > ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching > http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=linux-2.6-arm.git;a=commitdiff;h=f47ecb85ba > > This one has been drafted for human understanding here: > https://wiki.ubuntu.com/Specs/ARMSingleKernel > (the "Optimized virt_to_phys() with a runtime determined PHYS_OFFSET" section) >
Thanks for the links Nico. And the wiki page. Very useful. /Amit _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
