Optimized kernel builds: the straight dope

[Øivind Hoel]

I feel like such an idiot for even asking this question, but it's been
hanging on the back of my mind ever since I saw the first post about
dropping the i686 flavour. As I understand, the kernel should be able
to load any enhancing i686 stuff on demand, thereby making a seperate
i686 image completely redundant. However, does anyone have benchmark
data on running graphic intensive stuff like the Gimp, OpenGL games,
etc on i386 compared to i686?

Forgive me if I'm asking a silly question, but I think this is a valid usecase.

Regards, Øivind

On 8/20/06, John Richard Moser <nigelenki at comcast.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Rocco Stanzione wrote:
> > On Monday 14 August 2006 7:33 pm, Matt Zimmerman wrote:
> > <snip>
> >> I'm interested to hear (objective, reasoned) feedback on this data and my
> >> conclusions from the members of this list.
> >
> > The numbers are enough to convince me that we don't need to keep building
> > these cpu-optimized kernels.  It would be nice, though, to see smp kernels
> > that don't support 4GB of ram (and that don't incur the penalty for
>
> Supporting 4GB RAM and 64GB RAM involves entering PAE mode.  I'm pretty
> sure PAE mode is entered anyway to get an NX bit on newer x86 CPUs that
> have it.  Honestly though I don't know what the freg paging address
> extensions does beyond that :)
>
> I'm not sure if the overhead is actually significant.  18% of the
> system's CPU time is spent in the kernel in normal use; and a fraction
> of a percent of that is spent mucking about where this matters.  Unlike
> having a 4GiB VMA, high memory support doesn't make context switches
> take 5 times longer, so you won't get visible performance loss from
> syscalls and task switches suddenly being slower.
>
> > supporting it) and those that do support large amounts of ram without being
> > smp kernels.  Instead of saving kernel build times etc., more users would see
>
> An SMP kernel does (approximately) this:
>
> spin_lock(x) :
>   lock  ; only we access whatever the next insn touches
>   inc_if_zero x.count
>   jz spin_lock ;loop if that failed
>
> spin_unlock(x) :
>   lock
>   dec x.count
>
>
> A UP kernel does this:
>
> spin_lock(x) :
>   inc_if_zero x.count
>   jz spin_lock ;loop if that failed
>
> spin_unlock(x) :
>   dec x.count
>
>
> Now, these days, when an SMP kernel comes up and sees one CPU, it
> patches its own code so that it does this:
>
> spin_lock(x) :
>   nop   ; do nothing, 0 cycle instruction
>   inc_if_zero x.count
>   jz spin_lock ;loop
>
> spin_unlock(x) :
>   nop
>   dec x.count
>
>
> So all our kernels can be SMP with no detriment.
>
> > a real performance impact for the same number (?) of kernel images.
> >
> > Rocco
> >
>
> - --
> All content of all messages exchanged herein are left in the
> Public Domain, unless otherwise explicitly stated.
>
>     Creative brains are a valuable, limited resource. They shouldn't be
>     wasted on re-inventing the wheel when there are so many fascinating
>     new problems waiting out there.
>                                                  -- Eric Steven Raymond
>
>     We will enslave their women, eat their children and rape their
>     cattle!
>                   -- Bosc, Evil alien overlord from the fifth dimension
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQIVAwUBROi/OQs1xW0HCTEFAQICvg/+Ipmn1ZtLSUeZ+3fjoINI7uBB+Sj50QuU
> oM7kqQ2up98XUq8cP9OuhIE9AkugtnWpd7K9VrMDxtUhALFo2BlHcW4sLWoOULNE
> DoyG5+d9ncsOQWbI4XHsI/V05EIrpsaKRfw80T7SURXkRrbTrfC2rqP0BGTZ/RUx
> iFZeEFp13ven2pGEe12nkIg28QXG/6W+HbdP3LJLdrdJJYRfWuf1LHysWmmYa1jV
> bzYXDU+e3Slh+skDci9Vh5MzB8qjV+KalBswQWOSf2aT+V1DpRg2Oc4RrlxIPxue
> Hv4GNqTckZE76u4AycEErtZZv1ESkEkP5t7PCWxevm2sfSFANARVo+ELaK4hNZuz
> WrwFNHFdme9nojPJaPObpBIVKfyW49WxdMYk0G2IOSSAgvNUTgvTz9w+qEMLPPH3
> jnuA3IjcWBKifK8MSo+EroUBCgb8Bt+jiJ8pf913kY89lVUZBnPBJz/DdK4HOWFL
> 52xibf4HVQJyBRL9SEQOooOiU//fQuby3BVkpOdxudW9n4o//iPPucIGaucX+KpY
> Gpf+3JdbaPg1EwjbKnhd3EhobDlaJo+/HdEVVdeto57+1mMHg3dFUIsPdJWHI7Aq
> xBTFZaMevWYciYmnZRS29WWolDSyE1iB2rqckQn59pUyyjdL6qXih4D5dPup+TcT
> t26r99qH2+o=
> =MnyE
> -----END PGP SIGNATURE-----
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>


-- 

Øivind