[TriLUG] Kernel slowdown

[Daniel T. Chen]

On Tue, 1 Jan 2002, Scott wrote:

[...]
> the amount of time it took to delete the untarred/uncompressed Linux 
> source directory.  The vanilla 2.4.17 kernel took approx 28s, while 
> 2.4.17-preempt and 2.4.7-10 both took approx 13s.  However, the time 

For many interactive purposes the kernels after 2.4.9 will be slower
because of the new vm. Tar is a notoriously bad way of testing this
particular profile (for more information check the lkml archives for
November 2001; search for Andrew Morton's and Linus's posts about tar).

Also be aware of the difference between interactive "responsiveness"
(sluggishness in updating windows in X) and throughput.

This is also attributable to whichever filesystem you use in addition to
the elvtune settings you use.

> slowed considerably in the 2.4.17-preempt kernel (approx 19s) if I had 
> XMMS playing at the same time as deleting the Linux directory (not 
> surprising).

Indeed, since even kernel-level threads can be preempted if you use the
preempt patch to the scheduler.

> The problem is that the XMMS started to skip.  So bad, in 
> fact, that it became quite useless.

This can probably be remedied by using a combination of:
1) make XMMS suid and check the option to allow it to try and gain
   realtime priority
2) adjust your elvtune read settings (see elvtune manpage, and if it's
   not terribly straightforward, a Google search might help)

In my experience (ext3) the former option has more of an effect.

> These quick and dirty tests seem to point to several possible reasons 
> for a slow down: 1) The stock RedHat kernel has several patches in it 
> that are streamlined specifically for the RedHat distro (if so, what 
> are they)

Check the arch-specific portion of the .spec file. I highly doubt the
patches are the root of the apparent "slowdown."

> 2) I've compiled in something to both the 2.4.17 kernels that 
> really slows down my machine (if so, what could that be)

Blame the vm unless you plan on ripping it out and replacing it with the
one from 2.4.13-ac8... ;o)

> 3) It's the 
> fact that I'm using a strictly monolithic kernel while 2.4.7-10 is 
> modular (I thought modules slowed things down, not the other way 
> around)

Not this reason at all. Modules are _slightly_ (but negligibly) "slower"
because of entry and exit points but not enough to noticeably cause
writhing torment...

> 4) 2.4.17 sucks (it's Linux, how could that be?)

This one's arguable, though I've warmed considerably to the -aa vm
(which has markedly improved since 2.4.10) despite my preference for
Rik's in 2.4.13-ac8. ;o) Generally, I disagree with this choice. :)

> I'm curious so see if there is a general slowdown of the kernel (using 
> my VERY limited test) over the previous 10 releases (11 and 15 
> excluded) or if this is a new thing...or if I've somehow accidently 
> eaten a mushroom I wasn't supposed to and I'm hallucinating...or I'm 
> stupid and can't compile a kernel for doggy poopie.

There has been a noticeable slowdown since 2.4.4, 2.4.9, (2.4.13-ac8)...
so no, if you've been eating the 'shrooms you can still mask your
habits. ;o)

> So here comes the question section: 1) Has anyone else noticed this?

Yes, and you are certainly among multitudes. lkml archives attest to
that.

> 2) 
> What could cause it?

Some possible culprits are outlined above.

3) How could I fix it?

An interesting question with a few interesting responses:
1) Revert to the 2.4.13-ac8 vm (difficult, and unless you have a solid
   grasp of the vm structure, not recommended)
2) Check your fs's mount options...things like notail (reiser), noatime
   (all), etc. can create noticeable differences
3) Adjust your elvtune read setting

> 4) What is the airspeed 
> velocity of an unladened swallow?

I'm answering this one from the bottom of the gorge, so take it for
what you will... ;o)

---
Dan Chen                 crimsun at email.unc.edu
GPG key:   www.unc.edu/~crimsun/pubkey.gpg.asc