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: nice(39); while(1); 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): kernel-2.4.20-19.9.athlon How reproducible: Always 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.
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.
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/