Messages in this thread | | | Date | Wed, 22 Oct 2008 10:11:57 +0100 | From | Alan Cox <> | Subject | Re: [RFC] Kernel version numbering scheme change |
| |
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
| |