On Friday 25 July 2003 18:06, Malcolm Beattie wrote: > > * No processor affinity (threads are stuck on same CPUs always) > > Huh? Threads aren't "stuck on same CPUs" at all. The issue with > processor affinity is trying to keep related tasks on or near the > same CPUs where appropriate. 2.4 already does a certain amount of > this and, in any case, one of the strengths of the S/390 and > zSeries platforms is that with the huge shared caches, you don't > have to worry as much about switching between different CPUs. > Yet again, this has nothing to do with DB2 Connect and 2.4 is > still good.
Also, unless you are using dedicated CPUs, the effect of processor affinity in Linux is probably very low since VM will schedule around the CPUs that you try to stay on. There also is no concept of interrupt affinity on the zSeries platform, so you can not bind a process to the cpu that gets the interrupts, as e.g. the tux web server would like to. > > * Kernel is not pre-emptive > > Shouldn't affect enterprise workloads much if at all. Right. Note that it does not even work in 2.6 on s390. Unless you want to debug kernel preemption, don't bother to switch this option on. > > * I/O Scheduler is inefficient > > It varies from tree to tree and distro/version to distro/version. 2.6 > definitely has some nice stuff in there (deadline I/O scheduler, > anticipatory scheduler, pluggable schedulers) but an up-to-date 2.4 > tree will do fine. Even new I/O schedulers are not ideal for modern DASD, usually you end up with better performance when using no i/o scheduler or elevator algorithm at all, as we did in 2.4. In theory, you could have an optimized i/o scheduler for DASD, but that wasn't done for 2.6. Maybe for 2.7... > > * Single I/O global request lock for all I/O types (raw vs sync > > vs...) > > Yes, nice and separate in 2.6 but I don't know anyone for whom > this is a big problem in 2.4. The bigger problem is that the same request lock is used for all devices in 2.4. This should have a noticable impact if you have many DASD devices (e.g. for LVM) and access them simultaneously. We don't have any data on this, does anyone want to measure this? In general, the 2.6 kernel is in a rather good shape and everything you need make 2.6.0-test1 work on your box is available out there. However, *don't* expect it to work out of the box or as a drop-in replacement for 2.4. There are a number of known bugs (and a lot more that have not been found yet) and you need to update some of the user space tools. So far the feedback has been next to zero, which either means that everything works for all of you or nobody has done any testing. If you have problems with 2.6, please tell us, either here or with the bug tracking system at http://bugzilla.kernel.org/. > ...from home, speaking only for myself same here Arnd <><
