Today I had to rebuild a customer's Linux 2.6 kernel to enable >4G RAM
support, and while wandering through menuconfig found an option to the
scheduler that looks like it has some promise for application DB
performance. I realize this is not a Linux kernel support forum, but
there may be some collective wisdom here.

These are the three options possible:

=================================================================

CONFIG_PREEMPT_NONE:

This is the traditional Linux preemption model, geared towards
throughput. It will still provide good latencies most of the
time, but there are no guarantees and occasional longer delays
are possible.

Select this option if you are building a kernel for a server or
scientific/computation system, or if you want to maximize the
raw processing power of the kernel, irrespective of scheduling
latencies.

CONFIG_PREEMPT_VOLUNTARY: **DEFAULT**

This option reduces the latency of the kernel by adding more
"explicit preemption points" to the kernel code. These new
preemption points have been selected to reduce the maximum
latency of rescheduling, providing faster application reactions,
at the cost of slighly lower throughput.

This allows reaction to interactive events by allowing a
low priority process to voluntarily preempt itself even if it
is in kernel mode executing a system call. This allows
applications to run more 'smoothly' even when the system is
under load.

Select this if you are building a kernel for a desktop system.

CONFIG_PREEMPT:

This option reduces the latency of the kernel by making
all kernel code (that is not executing in a critical section)
preemptible. This allows reaction to interactive events by
permitting a low priority process to be preempted involuntarily
even if it is in kernel mode executing a system call and would
otherwise not be about to reach a natural preemption point.
This allows applications to run more 'smoothly' even when the
system is under load, at the cost of slighly lower throughput
and a slight runtime overhead to kernel code.

Select this if you are building a kernel for a desktop or
embedded system with latency requirements in the milliseconds
range.

=================================================================

The application I'm working with appears to be heavily bottlenecked
around lock contention, and mutex waiting for locks appears to cause a
lot of context switch activity.

I routinely see what looks like pathological locking behavior even
with a *single* process with incredible amounts of context switching,
and a bit of testing on an old Linux two-processor machine with the
first option - no pre-emption - "feels" like it's running a bit better.

Certainly there are no realtime latency concerns with a machine that's
running only as a DB server, so in that respect this option can't hurt.

But I'm looking for some kind of gut feel here: "Yah, that's a big
deal" -vs- "Won't be any more impact on Firebird than any other kind
of server app"

Thanks,
Steve

---
Steve Friedl | UNIX Wizard | Microsoft MVP | www.unixwiz.net