Bug 96978 - (SCHEDULER)SMP handling problems in the new kernel 2.4.20-18.8smp
(SCHEDULER)SMP handling problems in the new kernel 2.4.20-18.8smp
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-06-07 12:28 EDT by Rene Hansen Musvoto
Modified: 2007-04-18 12:54 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:41:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rene Hansen Musvoto 2003-06-07 12:28:44 EDT
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:
Actual results:

Expected results:

Additional info:

Best Regards

Rene Hansen
Open Systems Consultant - Aero Data
Bækkeskovvej 14
DK-2700 Brønshøj
Phone: +45 3879 9483
Cell: +45 4042 8483
Fax: +45 3871 8427
Comment 1 Arjan van de Ven 2003-06-07 13:16:44 EDT
the irq thing you can easily fix by doing
service irqbalance start
Comment 2 Rene Hansen Musvoto 2003-06-07 13:30:06 EDT
Works yes, thanks Arjan
Comment 3 Bugzilla owner 2004-09-30 11:41:04 EDT
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

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.