Bug 85723 - Renice doesn't behave as expected for multithreaded apps.
Renice doesn't behave as expected for multithreaded apps.
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2003-03-06 10:31 EST by simra
Modified: 2007-04-18 12:51 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-03-06 10:51:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Simple number cruncher using pthreads (723 bytes, text/plain)
2003-03-06 10:32 EST, simra
no flags Details

  None (edit)
Description simra 2003-03-06 10:31:06 EST
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):

How reproducible:

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.

Additional info:

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.
Comment 1 simra 2003-03-06 10:32:23 EST
Created attachment 90491 [details]
Simple number cruncher using pthreads

See bug report for further details.
Comment 2 Elliot Lee 2003-03-06 10:51:12 EST
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.

Note You need to log in before you can comment on or make changes to this bug.