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. Cheers ---Dave > >>> Absolutely that's the future... in fact the bootloader should work the >>> same >>> way with one per-arch bootloader that detects what it is running on at >>> runtime, and at that point device-specific point hwpacks become very thin >>> or >>> non-existent and there's an epic reduction in how many different binaries >>> are needed to support many boards. >> >> I can hear the collective sighs of appreciation from distribution >> maintainers :) > > ^^ > > -Andy > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
