[PATCH 00/12][RFC] Intial Kconfig Fragment Demo

Nicolas Pitre nicolas.pitre at linaro.org
Thu Mar 17 01:53:55 UTC 2011


On Fri, 11 Mar 2011, Amit Kucheria wrote:

> 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
> >>>> 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)


Nicolas


More information about the linaro-dev mailing list