Bug 96978

Summary: (SCHEDULER)SMP handling problems in the new kernel 2.4.20-18.8smp
Product: [Retired] Red Hat Linux Reporter: Rene Hansen Musvoto <rene.hansen>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:41:04 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:

Description Rene Hansen Musvoto 2003-06-07 16:28:44 UTC
Description of problem:

RedHat have just sent out a corrected kernel for RedHat 8/9; 2.4.20-13.8smp and
2.4.20-18.8smp, in my case.

First a little about the hardware:
I'm running a Workstation with two Pentium 4 type Xeon, 2.0 GHz and 1 GB of
memory, it's a Fujitsu Siemens Celsius 670. My hardware is setup for running
Multi Threading, which dos that my kernel thinks I have 4 CPU's.

Then to the time before these updates, running on kernel 2.4.18-27.8smp:
Normally, if I start 3 heavy loading processes, although in nice 20, on the
machine, they will tend to be bound on each there "CPU" and will only switch CPU
if the machine doing allot of other stuff.
This is the normal way of dealing with SMPs, and it have, by the way, worked
very very good and the hardware can really perform satisfying.

Now after the update:
If I start the same 3 processes, still nice 20, they are no longer bound on each
there CPU. No they are now "racing" around between the CPU's like crazy. The
result is that the machine uses all the overhead to perform the context
switchings. That's kind of creepy. One other things I have noticed too is that
all interrupts are handled by one CPU only, and not divided as needed one each
of the 4 CPU's

All in all the result is that the machine is no longer performing properly, it's
kind of jumpy. Things like audio and video streaming is no longer possible.
Things will get full of "holes" or rather missing parts.

This "problem" was corrected all the way back in kernel 2.4.8 long time ago, but
seems to be reintroduced in this new kernel 2.4.20....


Version-Release number of selected component (if applicable):

Kernel 2.4.20-18.8smp

How reproducible:

Start 3 seti processes with -nice 20. Then try and run some video or audio files
with whatever software.  Try and start xosview and check how the processes are
jumping around. Look in the interrupts view's and notise that only one cpu is
handling them, normaly all cpu are suppose to handle each there interupts.

Steps to Reproduce:
1.
2.
3.
    
Actual results:


Expected results:


Additional info:

Best Regards

Rene Hansen
Open Systems Consultant - Aero Data
Bækkeskovvej 14
DK-2700 Brønshøj
Denmark
Phone: +45 3879 9483
Cell: +45 4042 8483
Fax: +45 3871 8427

Comment 1 Arjan van de Ven 2003-06-07 17:16:44 UTC
the irq thing you can easily fix by doing
service irqbalance start


Comment 2 Rene Hansen Musvoto 2003-06-07 17:30:06 UTC
Works yes, thanks Arjan

Comment 3 Bugzilla owner 2004-09-30 15:41:04 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/