On Fri, Mar 11, 2011 at 12:32 PM, Dave Martin dave.martin@linaro.org wrote:
On Wed, Mar 9, 2011 at 9:13 AM, Andy Green andy@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