Gustasson, Julian X writes:
> Yesterday, one of my colleagues forwarded me the following note (from an
> as-of-yet unidentified third party):
>
> -----------------------
> "I've listed out the main performance problems with 2.5. The point here is
> that,
I'll assume the author means 2.4 since 2.5 *is* the tree with
2.6-to-be stuff in it.
> given what you're doing with DB2 Connect, Linux would be a ridiculous
> choice prior to a 2.6 kernel."
That turns out not to be the case. Plenty of people are using
DB2 Connect happily with 2.4.
> "Yes, we benchmarked Oracle on Linux and it was faster than Windows...
> But that's not really saying anything, now is it? :)"
> -----------------------
>
> The alleged performance flaws that he identified were:
>
> ---------------------
> Pre 2.6 Linux Limitations---
>
> * High amount of "Big Kernel Locks" still being used (versus small
> semaphore locks) for TTY traffic, memory access, etc. (will be reduced in
> 2.6)
BKL usage is being reduced but it's going from "low to even lower"
rather than "high to low". TTY traffic is pretty much irrelevant to
mainframes (no physical terminals so it's pseudo-terminals only and
even if a workload did have lots of people logging in on ptys, I doubt
BKL would be an issue except in *really* unusual cases--and those
cases have nothing to do with DB2 Connect. "Memory access"? I don't
see any connection between copy_{from,to}_user and the BKL and I
don't know what else could be meant by "memory access".
> * Global Locks for (I/O requests, IRQs, etc.)
Certainly one of the nice things about 2.5/6 is the I/O layer changes
with a lock per request queue instead of a global lock. That, along
with the rest of the block layer rewrite, should be very nice for I/O
intensive workloads. However, 2.5 is "even better" while 2.4 is just
"good". Again, there's nothing ridiculous about using 2.4 and, again,
this has nothing to do with DB2 Connect.
> * 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.
> * Kernel is not pre-emptive
Shouldn't affect enterprise workloads much if at all.
> * Buffer cache and page cache managed separately (slower)
Hmm, sorta separately but not *that* separately (and I'd call 2.5/6
"faster than 2.4" rather than "2.4 slower than 2.5" if you see what I
mean. No if you compared 2.0 going to 2.2 (buffer cache was much more
separate then and 2.2 introduced a "read-through page cache" while the
write path still got copied out through buffer cache) or 2.2 going to
2.4 (which fixed it up so the page cache was "write through" so there
was no more extra copy) then you might have a point. (Heck, sometimes
even metadata is getting put in page cache, these days.) 2.5/6, though,
teases apart any remaining messy buffer/page cache connections and
the I/O layer now has an I/O "tag" structure rather than mixing it up
with buffer_heads and buffer cache. The design looks and works much
more cleanly in 2.6 but 2.4 is still fine from a performance view for
most workloads. (Again, irrelevant for DB2 Connect).
> * 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.
> * 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.
> * Old Scheduler still being used:
> o Global run-queue holds all runnable processes (slow when queue is
> long)
> o Reschedule scans requires full run-queue scan to find next process
> to run (limits SMP scalability)
> o Time-slice recalculation after all slices have been consumed (slow
> process when queue is long)
> o No facility for more efficient wakeup, interrupt, schedule timers
> o No load balancing between CPUs
> o Unnecessary context switches for procs / threads sleeping
The O(1)-scheduler which "fixes" this (more precisely, lets coders
get away with sloppier threading designs without penalising them :-)
is already back-ported to 2.4 and included, for example, in SLES8.
> Can some of the internals gurus on this list comment on these claims and
> whether they are relevant to Linux under VM? I have my own speculations, but
> I wanted to see what the facts were.
When a new version of a piece of software comes out (or is about to
come out), some people get in a state of mind where they think that it
means that the previous version is dreadful. Sometimes this is because
they've worked on (part of) the new version and so concentrated on the
particular narrow problem area so much that they can no longer see the
big picture. Sometimes it's because somebody less familiar with the
detail of the changes sees a list of all the nice new features and
improvements in the new version and thinks that means that the previous
version was bad in absolute terms rather than relative terms in all
those areas. Letting such people have too much influence over the
choice of what software to run for a real workload in real life in the
here and now is unlikely to be a very good idea.
Hope this helps.
--Malcolm
--
Malcolm Beattie <[EMAIL PROTECTED]>
Linux Technical Consultant
IBM EMEA Enterprise Server Group...
...from home, speaking only for myself
