On 06/22/2011 01:34 PM, Robin Gareus wrote:
On 06/21/2011 09:03 PM, Ralf Mardorf wrote:
Hi,
could there be any disadvantages for averaged desktop users, server
usage etc., if the kernel 2.6.39 is build as PREEMPT kernel?
Today I installed the kernel from the repositories of a major Distro:
$ uname -a
Linux debian 2.6.39-2-amd64 #1 SMP Wed Jun 8 11:01:04 UTC 2011 x86_64
GNU/Linux
Some time ago I build the kernel myself:
$ uname -a
Linux debian 2.6.39.1 #1 SMP PREEMPT Tue Jun 7 01:40:05 CEST 2011 x86_64
GNU/Linux
I'm asking, because I want to know, if it would be reasonable to appeal,
that major distros should build it as PREEMPT kernel.
Well, they should offer the option (a kernel-flavor - compare to -bigmem
or -xen, or -vserver, etc). but as default: no.
Preemptive scheduling introduces some overhead [for each process] and
effectively reduces throughput.
As the vast majority of systems (both Desktop and Server) do not run any
processes with SCHED_FF or use elevated scheduling priorities. Thus
there is no benefit and only drawbacks (the machine is a tiny-bit slower
and consumes more power with a PREEMPT kernel).
if you're about to "emulate" the PREEMPT_RT (aka. -rt) kernel the best
you can, with increased reliability on SCHED_FF scheduling (aka.
realtime scheduling, which is "bread & butter" for the whole jack
ecosystem) and provided you turn on the forced irq threads kernel boot
option (threadirqs) then PREEMPT is certainly the one to configure your
custom kernel.
beware, VOLUNTARY_PREEMPT (intended for general purpose desktops?) and
PREEMPT_NONE (certainly only for servers?) will just give you lousy,
xrun-prone system, with no resemblance whatsoever with a good old but
true -rt kernel ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org