Bug 85723

Summary: Renice doesn't behave as expected for multithreaded apps.
Product: [Retired] Red Hat Linux Reporter: simra
Component: util-linuxAssignee: Elliot Lee <sopwith>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-03-06 15:51:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Simple number cruncher using pthreads none

Description simra 2003-03-06 15:31:06 UTC
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:
Always

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 15:32:23 UTC
Created attachment 90491 [details]
Simple number cruncher using pthreads

See bug report for further details.

Comment 2 Elliot Lee 2003-03-06 15:51:12 UTC
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.