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): 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.
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.