Red Hat Bugzilla – Bug 85723
Renice doesn't behave as expected for multithreaded apps.
Last modified: 2007-04-18 12:51:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210
Description of problem:
When I run a multi-threaded application, with a number-crunching worker thread,
and I want to renice +19 the process, the worker thread continues to behave as
if it had the default priority.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Assuming uniprocessor machine:
1. Compile the attached c file (see header comments)
2. Run two instances of the resulting program.
3. renice +19 one of the instances by it's pid (from ps -a, or top, etc)
Actual Results: Run top and observe that the reniced process continues to use
roughly 50% of the CPU.
Expected Results: The reniced process should use much less cpu time.
Note that if I had run one of the instances directly with 'nice', there is no
problem- only renice is impacted.
I suspect that the parent thread is the only one being reniced. The issue here
is that the child threads aren't being impacted by a reniced parent. You might
say: explicitly renice the child threads by their pids, but by default these
pids are not displayed by ps or top. In my opinion, renicing the manager thread
should renice everyone else as well, whereas fine-grained renicing can be
achieved individually if desired. There were good reasons why ps and top no
longer display thread pids, and there should be some consistency in how the
utilities treat them- if top says pid X is taking 50% of the cpu and I renice
it, then the outcome should reflect the action.
Created attachment 90491 [details]
Simple number cruncher using pthreads
See bug report for further details.
This is a side effect of the way linuxthreads implements things. There is just no way to fix
it in linuxthreads, but NPTL does solve it (see rawhide), so once that becomes widely
used, you'll have your fix.