Bug 96978 - (SCHEDULER)SMP handling problems in the new kernel 2.4.20-18.8smp
Summary: (SCHEDULER)SMP handling problems in the new kernel 2.4.20-18.8smp
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-06-07 16:28 UTC by Rene Hansen Musvoto
Modified: 2007-04-18 16:54 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:41:04 UTC
Embargoed:


Attachments (Terms of Use)

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/



Note You need to log in before you can comment on or make changes to this bug.