Re: [RFC] Kernel version numbering scheme change

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Wed, 22 Oct 2008 09:58:06 +0100
Alex Howells <alex@bytemark.co.uk> wrote:

> > And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
> > that worked reliably under the proper "beat on the scheduler/VM corner case"
> > load/stress testing.  Again, the best you can hope for is "doesn't fall over

Upstream kernels can be a bit iffy especially on 32bit boxes with lots
of RAM. The enterprise vendor kernels have had months of tuning on high
load tests and behave far better than upstream. If you are running 32bit
and > 2GB of RAM I wouldn't even bother with upstream kernels to be
honest - pick one of the enterprise distributions or free repackagings
thereof. Better yet go 64bit ;)

At minimum with 2.6.x under high load you also need Arjan van de Ven's
patches to fix the ioprio mess - and god knows why those haven't been
accepted upstream given they make a huge difference to performance and
load handling.

http://lkml.org/lkml/2008/10/2/297

> > under non-pathological non-corner-case loads when sufficient resources are
> > available so the kernel has a fighting chance".  Doing 'make -j100' on a
> > single Core2 Duo is gonna be painful, no matter what.

Turn on strict overcommit and the box will degrade sanely and then if
need be start erroring things with out of memory before it goes kersplat.
That was a feature added a long time ago by Red Hat and then merged
upstream because serious business users of Linux need better guarantees
than the base kernel defaults.

If you have a non AMD processor without an IOMMU and are doing high
amounts of I/O make sure your I/O devices are 64bit capable - particular
watch SATA as most ATA hardware that isn't AHCI is 32bit constrained.

Alan