Bug 109420
| Summary: | Kernel latency issues | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Yue Shi Lai <ylai> | ||||||
| Component: | kernel | Assignee: | Larry Woodman <lwoodman> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 3.0 | CC: | burt, jan.iven, jos, k.georgiou, mingo, nobody+wcheng, petrides, richard.cunningham, riel, smithj4, tburke | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2007-10-19 19:33:19 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Yue Shi Lai
2003-11-07 18:08:33 UTC
sounds like you need to increase the default buffer size. You're not using KDE are you ? No, I also tried to increase the buffer size to 10 seconds, but with no effect. I am using GNOME. Some additional information: 1. Much more visible is this problem when using Wolfram Research's Mathematica 5 when running XMMS. Beside other circumstances, just left click on any place of a Mathematica notebook will halt XMMS playing after few seconds (shorter than the actual XMMS buffering size). I think this way to reproduce the problem shows very well that the XMMS buffering and buffer size is unrelated to this problem, since the buffer is not even empty, when XMMS stops playing. 2. This problem is actually and contrary to my previous report sensitive to Mozilla scrolling, however, only with very big and graphics intensive pages. If I might ask: Is the "O(1) scheduler starvation" as discussed in June on the Linux Kernel Mailing List related to this issue? http://lkml.org/lkml/2003/6/18/102 After reading the kernel mailing lists, if I am not very mistaken, what we need here is a backport of the 2.6.0 kernel with O(1) scheduler interactivity patch. This seems also have solved the problem in Fedora Core (Bug 100422). Then the question would be, when can it be intergrated in RHEL? Created attachment 96598 [details] Backport of Con Kolivas' patch-test5-O20.3int This is the patch I made, which solves the issue mentioned. It can be applied as the patch no. 50 in the source RPM spec of kernel-2.4.21-4.0.1.EL.src.rpm. Please note that this is a very minimalistic patch. It especially does not change the logic towards the idle variable in can_migrate_task() (also see http://www.ussg.iu.edu/hypermail/linux/kernel/0308.3/0879.html), as implemented in kernel 2.6.0-test6 and later and Fedora Core 1. As like the current kernel, sched_clock is implemented for arm, i386, ia64, ppc, ppc64, s390, sparc64, and x86_64. However, I could only tested this patch on i386 architecture, first in VMware and then natively. It seems to be stable and show the expected enhancement of the scheduling behavior. The last paragraph of comment #6, first sentence is wrong: As like in 2.6.0-test6, ... We have just frozen the Update 1 kernel (beta is already available), so I would like to propose your patch for the Update 2 MUSTFIX list. Ingo, any objections to the O(1) interactivity patches ? oh boy, Con's patch has certainly grown from the earlier versions we may need to look at chainsawing this down to a much smaller change set, the current patch is way too big for a "minimal changes only" policy Concerning the patch backport, I encounted the following issue: VMware Workstation is getting too much CPU time during strong Guest loads (e.g. booting an OS). The system becoms a "stop and go". Renices all VMware threads to the nice value of 0 resolves the problem. This maybe due to the fact that VMware "looks" interactive to the scheduler and also renices it to -10 (and lower for the I/O threads). Since VMware has already released a Beta version of VMware Workstation 4.1, and its release note states that it is more suitable for 2.6 kernel series, I will do some testing with this version the next days. Bug 113851 maybe related to the observation I made. Any news on this problem? The U2-beta kernel (2.4.21-12.EL) does still not solve the XMMS problem :-(. Could this possibly be related to bug #121434 here: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121434 I have similar experiences on my desktop, which is showing horrible latency with the latest kernel: 2.4.21-15.0.4.EL Maybe there are two problems, one raid related and another problem either with the kernel scheduler or the IO elevator. This is a problem for me with xmms under kernel-2.4.21-20.EL, about 3-4 times a minute - its really annoying. Created attachment 108040 [details]
2.4.21-20.0.1 version of Backport of Con Kolivas' patch-test5-O20.3int
Its still a problem under kernel-2.4.21-25.EL (latest beta) and
kernel-2.4.21-20.0.1.EL (latest patched version).
I've applied the back port of Con Kolivas's Patch which fixes it (I've been
using it the last couple of days), I've supplied an updated version with the
file manually updated as I had to do this because a couple of hunks failed to
match. The Patch is to be applied to the 2.4.20.0.1.EL kernel.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you. |