Red Hat Bugzilla – Bug 102278
extremely slow scheduling with rpm
Last modified: 2007-04-18 12:56:50 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):
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.
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.
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
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
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/