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. /Amit _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
