Bug 102278 - extremely slow scheduling with rpm
extremely slow scheduling with rpm
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-08-13 07:04 EDT by nvwarr
Modified: 2007-04-18 12:56 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:41:26 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 nvwarr 2003-08-13 07:04:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
When a program is running nice'd, an rpm install (of any product) runs extremely
slowly. For example, an install which takes 2.2 seconds normally, takes 5
minutes. Of those five minutes, however, only 1.6 seconds were user time and 0.5
seconds system time (comparable to the normal case). Strace indicates that the
rpm process is simply having to wait for ages between each system call before
being scheduled again.

The problem was detected while trying to install rpm packages with seti@home
running, however, the same effect can be produced with a simple program which does:

I haven't found any other programs other than rpm which exhibit the problem. I
am using rpm-4.2-1.

Downgrading to kernel-2.4.20-19.8.athlon fixes the problem.

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

How reproducible:

Steps to Reproduce:
1. Start a program which eats CPU using nice
2. Use rpm to install a package

Actual Results:  rpm takes over 100 times longer to complete than normal.

Expected Results:  Since rpm is not running nice'd it should have priority over
the nice'd program and execute more or less at normal speed.

Additional info:

I started off thinking this was the lock files bug in rpm and following the
advice on bugzilla for that bug, upgraded rpm. That definitely made a
difference, but it is possible that the problem with rpm was simply that I
didn't wait long enough (i.e. I gave up after a few minutes when top wasn't
showing any activity from rpm) and kill -9'd it.

With kernel-2.4.20-19.8.athlon and rpm-4.2-1 the problem seems to go away.
Comment 1 nvwarr 2004-01-26 07:16:41 EST
The problem remains kernel-in 2.4.20-28.9. Also I've been able to
reproduce it on two computers (both athlons).

The problem seems to be in the native posix thread library patches.
Removing those patches (by changing the define nptlarchs line to
noarch in the .spec file) fixes the problem. (Vanilla kernels are fine).

I don't think the problem is specific to rpm at all, but that seeems
to be the easiest way to trigger it. Something in the nptl stuff
causes syscalls to run slower than on the same machine without the
nptl patches.

So the workaround is to download the SRPM, modify the .spec file to
change the %define nptlthreads line (the spec file already has a
commented out version), rebuild the rpm and install. Though,
presumably this defeats the whole purpose of including nptl in the
redhat kernel.
Comment 2 Bugzilla owner 2004-09-30 11:41:26 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.