Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 88216

Summary: Scheduler behaves strangely when running 2 or more GL apps
Product: [Retired] Red Hat Linux Reporter: Greg Corson <greg_corson>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: gmotor, k.georgiou
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:52:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Greg Corson 2003-04-07 18:39:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
When running two or more graphics applications the scheduler seems to be
alternately pausing each application for a half second or more resulting in
jerky stops and starts in each open window.

This is on a system running NVIDIA accelerated drivers but I don't think the
problem has anything to do with the drivers themselves.  If we switch the kernel
to one built from sources (2.4.20) the problem goes away.  We can run
as many GL apps as we like and they are all smooth.

This leads me to suspect that there is something in the RedHat kernel scheduler
that is different from a stock kernel and is not scheduling applications correctly.

Version-Release number of selected component (if applicable):
All RedHat 8 and 9 kernels so far

How reproducible:

Steps to Reproduce:
1.setup a machine with NVIDIA 3d acceleration 3 copies of glxgears at once
3.seperate the windows so you can see all 3 at once, note how they keep starting
and stopping.

Actual Results:  You get 3 windows running glxgears, that seem to be getting
pre-empted from by the scheduler for about half a second at regular intervals.

Expected Results:  The three windows should all run relatively smoothly, without
obvious pauses.  This is what happens if you run a stock 2.4.20 kernel from

Additional info:

We have observed this behavior on every machine we have tested both athlon
machines and intel based.  All are 2ghz or faster with no other programs running
at the time of the test. The problem is always fixed by using a stock 2.4.20 kernel.

The problem was first noticed on a RedHat 8 install and has continued with all
RedHat 8 updated kernels and with RedHat 9.

Comment 1 Arjan van de Ven 2003-04-07 18:44:23 UTC
sounds like a nvidia interaction with our changed scheduler indeed.

*** This bug has been marked as a duplicate of 73733 ***

Comment 2 Greg Corson 2003-04-07 19:47:15 UTC
Ok, I've retested on several machines with SOFTWARE ONLY GL.  This problem does
not appear HOWEVER running even one copy of glxgears makes the system almost
totaly un-responsive.  Moving windows, pulling up menus...etc all take 20-30
seconds if you can get them to work at all.

The scheduler appears to be giving all the CPU time to X and leaving nothing for
any other task.  I don't know if you would call this a bug but I don't recall it
happening with RedHat 7.x releases.

Possiblly this is an artifact of having X run at nice -10?

Comment 3 Motor 2003-08-16 19:55:01 UTC
My setup:

Athlon 2000XP, Gigabyte K7 Triton Motherboard, 512Mb RAM, Matrox G550, RH9 +

I'm seeing exactly the problem described above. Two instances of glxgears and
the scheduler seems to misbehave. Start four running and the problems are even
more pronounced.

This is with a *MATROX* card... not an nvidia.

Comment 4 Red Hat Bugzilla 2006-02-21 18:52:32 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.