SMP kernels on single processor machines

Hi,

putting together another release of the Debian kernel image packages,
I am wondering whether we could get rid of half the packages by simply
not supplying single processor flavours - after all, SMP kernels run
fine on single processor machines.  I have repeatedly been told,
however, that this bears a considerable performance hit on some
hardware.  Can anybody confirm or deny this?  Even small hints would
be appreciated.

Regards, Jens.

--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Jens Schmalzing wrote:

SMP kernels run
fine on single processor machines.  I have repeatedly been told,
however, that this bears a considerable performance hit on some
hardware.  Can anybody confirm or deny this?  Even small hints would
be appreciated.

A long time ago, I used to compile SMP into my kernels just on the
coolness factor, and on the promise that 'one day, soon, I'll get me a
decent machine' :)

But I quit doing that at some point, after someone (authoritative, but I
can't remember the details) pointed out that it added complexity,
debugging issues, etc.  Given that I *already* have problems with PPC
kernels -- latency/lockups, (preempting?), alsa sound, video res, etc.,
I personally wouldn't go near this until I'm fairly confident that the
other stuff is solid in its own right.

But then, I'm just a luser, not a kernel maintainer ;D

--
Lee Braiden
lee_b@member.fsf.org


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 2004-05-20 at 21:48, Lee Braiden wrote:

But I quit doing that at some point, after someone (authoritative, but I
can't remember the details) pointed out that it added complexity,
debugging issues, etc.  Given that I *already* have problems with PPC
kernels -- latency/lockups, (preempting?), alsa sound, video res, etc.,
I personally wouldn't go near this until I'm fairly confident that the
other stuff is solid in its own right.

But then, I'm just a luser, not a kernel maintainer ;D

Yah, well... CONFIG_PREEMPT gives you all the problems of SMP without
any benefit so .... :)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On 20-May-2004 Benjamin Herrenschmidt wrote:

On Thu, 2004-05-20 at 21:48, Lee Braiden wrote:

quoted

But I quit doing that at some point, after someone (authoritative, but I
can't remember the details) pointed out that it added complexity,
debugging issues, etc.  Given that I *already* have problems with PPC
kernels -- latency/lockups, (preempting?), alsa sound, video res, etc.,
I personally wouldn't go near this until I'm fairly confident that the
other stuff is solid in its own right.

But then, I'm just a luser, not a kernel maintainer ;D

Yah, well... CONFIG_PREEMPT gives you all the problems of SMP without
any benefit so .... :)

2.6.6 has the CONFIG_PREEMPT option so I thought it was stable.
Isn't it ?  What are the known problem ?  Is only preempt+smp
known to have problems ?


--
Giuliano.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, 2004-05-21 at 20:34, Giuliano Pochini wrote:

2.6.6 has the CONFIG_PREEMPT option so I thought it was stable.
Isn't it ?  What are the known problem ?  Is only preempt+smp
known to have problems ?

Well, there are 3 different things.

One is stability. I don't know of any ppc-specific problem with preempt,
though I do have reports of people experiencing problems (mostly various
kinds of segfaults) when it's enabled. I'm not sure what is to blame at
this point, possibly one of the filesystems.

Another is overhead. Preempt definitely adds overhead to the kernel. The
spinlocks, on an UP kernel, are mostly NOPs, while with preempt, they are
actually implemented (among others). Overall, preempt adds overhead to the
kernel.

Finally, the supposed benefit. Mostly a myth imho.

For those who didn't get it (yes, that happens), the kernel, even without
preempt, will preempt user processes :) Linux has always been a preemptible
operating system. CONFIG_PREEMPT only concerns the ability for the kernel
to preempt itself when a process triggers a potentially long operations
within the kernel.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Benjamin Herrenschmidt wrote:

Yah, well... CONFIG_PREEMPT gives you all the problems of SMP without
any benefit so .... :)

Well, I know people argue about that, but I think it was you who advised
me to avoid PREEMPT before, so I'll take your word for it.

But... what you said above was exactly my point.  There are no benefits
for single-cpu machines running an SMP kernel, right?  So it would
introduce more complexity for no gain.  Moreover, I think(?) the
majority of ppc machines are non-smp, so it would also be a shift to a
more obscure and (even) less well-tested config.

--
Lee Braiden
lee_b@member.fsf.org


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, 21 May 2004, Lee Braiden wrote:

Benjamin Herrenschmidt wrote:

quoted

Yah, well... CONFIG_PREEMPT gives you all the problems of SMP without
any benefit so .... :)

Well, I know people argue about that, but I think it was you who advised
me to avoid PREEMPT before, so I'll take your word for it.

But... what you said above was exactly my point.  There are no benefits
for single-cpu machines running an SMP kernel, right?  So it would
introduce more complexity for no gain.  Moreover, I think(?) the
majority of ppc machines are non-smp, so it would also be a shift to a
more obscure and (even) less well-tested config.

FWIW, CONFIG_PREEMPT _does_ reduce the avarage scheduling latency.
It's still sort of soft real-time, but the effect is measurable (I'm
talking 2.4 kernels here, BTW) However, on desktop systems you
probably don need to worry about this, but for an embedded system you
may like the slightly improved reaction time.

Regards,
Marius

--
Marius Groeger [off-list ref]           Project Manager
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, 2004-05-21 at 22:58, Marius Groeger wrote:

FWIW, CONFIG_PREEMPT _does_ reduce the avarage scheduling latency.
It's still sort of soft real-time, but the effect is measurable (I'm
talking 2.4 kernels here, BTW) However, on desktop systems you
probably don need to worry about this, but for an embedded system you
may like the slightly improved reaction time.

Well... average latency is mostly meaningless, only peak latency really
matters for anything that need some sort of real time imho...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/