Description of problem: This kernel fails the XMMS test miserably. Time sensitive processes such as XMMS and mplayer "skip" very frequently when doing various actions requiring either disk i/o or cpu time. Version-Release number of selected component (if applicable): 2.4.21-20.1.2024.2.1.nptl (athlon) How reproducible: I am able to reliably reproduce this several times a minute during normal desktop usage. Steps to Reproduce: Start XMMS and play an OGG file (with 'built-in' decorder) or an MP3 file (with a third-party decoder). While XMMS playing do one or all of the following: 1. find / 2. use the scroll wheel in mozilla or load a new page with lots of images 3. ls -lR /usr/lib (over and over again) 4. find /proc (over and over again)
I suspect this is a CPU scheduler issue, the O(1) scheduler unfortunately has a few known issues that aren't solved yet in any kernel version. During heavy IO my 500 MHz Celeron with 512MB of RAM is still snappy, but heavy CPU consumption does indeed make the desktop less responsive...
*** Bug 100440 has been marked as a duplicate of this bug. ***
I am seeing this behavior as well. The RHL 8 kernel didn't have this problem. The RHL 9 kernel was when I first started noticing interactivity slowdowns. However, the Severn kernel is much, much worse. Resizing a window will bring XMMS to a complete halt until the resizing is done. After some investigation, it seems this issue only occurs on uniprocessor boxes. Once I added a second CPU to my workstation and installed the SMP Severn kernel, things worked flawlessly.
The kernel in Fedora Core Test 2 seems to fix this issue for me (as far as xmms skipping goes). I'm assuming Con's patches were backported from 2.6.0-test5-bk?
Glad to hear its working out. Yes, some of the scheduler improvements from recent 2.6 are now in Fedora.
This problem seems also to be present in the up current Red Hat Enterprise Linux kernel.
Please open a new bug for RHEL reports. The scheduler there is quite different to what we have in FC.