[PATCH 00/12][RFC] Intial Kconfig Fragment Demo
amit.kucheria at linaro.org
Fri Mar 11 10:57:09 UTC 2011
On Fri, Mar 11, 2011 at 12:32 PM, Dave Martin <dave.martin at linaro.org> wrote:
> On Wed, Mar 9, 2011 at 9:13 AM, Andy Green <andy at 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
>>>> you mentioned and it isn't really using the same config for say igep0020
>>> 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
>>>> uniprocessor to consider too.
>>> Apparently, with this one-time patching (per boot) there isn't such a
>> 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.
More information about the linaro-dev