Red Hat Bugzilla – Bug 264481
Recent kernel update killed overall performance
Last modified: 2007-11-30 17:12:14 EST
Description of problem:
I was out of the office for the past two months or so. When I returned I did a "yum update" in fedora.
This pulled down a new version of the kernel. VMWare (after patching) is now unbelievably slow (it
takes several minutes for the application to open, much less start a virtual machine). My own software
(straight C code terminal app, no GUI etc) is also about 25% slower. Was there a new scheduler or
Version-Release number of selected component (if applicable):
Unknown -- from an update in the past 9 weeks.
Steps to Reproduce:
1. Run my own executable under "time", or launch VMWare (version 5.x)
My own executable takes roughly 25% longer to run, while VMWare (the app itself, not a virtual
machine) is almost unusable.
The same performance as 9 weeks ago.
This might be difficult to pin-down. Could someone help me downgrade the kernel so I could identify
the update that broke everything?
(In reply to comment #0)
> Steps to Reproduce:
> 1. Run my own executable under "time",
What is the output, under the new and old kernels?
And can you try this kernel?
Boot into the 2.6.20 kernel and remove the previous 2.6.22 one, then install
this one (using rpm). That way there will only be one 2.6.22 version installed.
I don't have the exact values, but it is roughly:
old kernel, user: 3m 25s
new kernel, user: 4m 45s
I will not have access to the machine until next week. How should I remove the previous 2.6.22 kernel?
We need the complete output of the 'time' command. (And the user time reported
may just be an artifact of the way the new sceduler does accounting, does it
really take more wall clock time?)
To erase the old kernel (as root)
# rpm -e kernel-2.6.22.whatever.fc6
Install the new one (all on one line):
# rpm -i
Ah, of course. Thanks. Yum has spoiled me.
Here is the output of the 'time' command with the current kernel (I do not have one saved from 9 weeks
The old executions looked very similar, but took roughly user 3m25s, real slightly larger.
My application does seem to take more wall-clock time, and VMWare certainly is much much slower.
I'll try the new kernel as soon as I have local access to the machine.
Here is the timing with version 22.214.171.124-49
I haven't tried to recompile the VMWare drivers to see if it helps with that.
Oh, by the way I only had 126.96.36.199 and 188.8.131.52 installed. What was the last
version of the FC6 x86_64 kernel with the old scheduler so I can try that again?
(In reply to comment #6)
> Oh, by the way I only had 184.108.40.206 and 220.127.116.11 installed. What was the last
> version of the FC6 x86_64 kernel with the old scheduler so I can try that again?
kernel 18.104.22.168-49, in the updates-testing repo, has the latest scheduler updates.
Ah, what info do you need?
I'm planning to revert to kernel-2.6.20-1.2962.fc6 and test as soon as I have local access to the machine
again (probably next Tuesday).
Other than this, I'd assume it's fallout from Ingo's CFS merge? Seems like it might be "fair" to the
detriment of a heavy computational task. Something tunable? Worth firing a message to LKML? If so, I'd
rather someone more versed in kernel details do so if possible.
(In reply to comment #9)
> Ah, what info do you need?
Results from 2.6.20 and from 22.214.171.124-49, which has the latest CFS scheduler.
126.96.36.199-49 is in updates-testing:
# yum --enablerepo=updates-testing update kernel
To keep more kernels installed than the default of 2, edit
/etc/yum/pluginconf.d/installonlyn.conf and change 'tokeep=2' to some larger number.
Resuts from 188.8.131.52-49 are in comment #5. Very small improvement. I'll get 2.6.20 next week.
Reinstalling 2.6.20-1.2962 resulted in no change:
Thus it seems like it is something other than the kernel. I suppose this bug
should be closed in some fashion. I'll open a new bug if I can figure out what
caused the slowdown I'm seeing.
Thanks for all of your help,