site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 30 Jul 2009, at 11:33, Terry Lambert wrote: No, it was just a command line app. This was my latest test: a) compile this program as "loop": int main() { while (1) {} } -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jul 30, 2009, at 3:01 AM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote: On Jul 30, 2009, at 1:05 AM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote: I wanted to use it for distributed.net, which is similar to SETI@home. The problem with letting the system decide what to about it, is that in this case all other applications get severely slowed down. E.g., when only running one other application at regular priority, the cpu time distribution appears to be about 40% for the nice -n 19 process and 60% for the other. That made me stop running distributed.net, because such a slowdown for regular apps was simply not acceptable to me. Were you running distributed.net with a GUI, which would make at least the GUI portion an actual RT priority thread, or did you run it headless, as a non-CFRunLoop app, not using Carbon or CoreFoundation interfaces which might trigger it being thought of as a GUI app? You niced down your "idle" process; did you also nice up your preferred process, or nice it less down to fix its scheduler prioity, which would otherwise get depressed due to a non-empty ready-to-run queue? I kept all other processes at their regular priority. It's kind of a pain to have to "sudo renice -n -19" all GUI apps I start. Furthermore, even in that case with just one other app running, the low priority one still gets 25-30% of the cpu. So long as you trap a process in the BSD "nice" range using explicit prioritization, a CPU intensive task at a higher priority will not be preempted by one of a lower priority through having its effective priority depressed for fairness reasons. See the xnu source code or Amit Singh's book for details. b) disable all but one CPUs using the Processors pref pane (part of CHUD) c) in Terminal window 1, do "sudo nice -n -19 ./loop" c) in Terminal window 2, do "nice -n 19 ./loop" d) check the cpu usage in top This results in the above-mentioned 25%/70% division (the rest is consumed by top, terminal etc) If you did all that and shark still showed 60/40 when you think your preferred app should have taken more CPU, and you verified your app is not stalling naturaly with a CPU intensive dummy load for comparison, you should file a bug report, including your shark trace. Does this still warrant a bug report? I don't know. Using top to get your numbers us statistical at best, so it's the wrong measuring tool; shark is the right tool here. Your while loop program didn't itself call nice, so as it chewed up CPU it was not at BSD fixed priority, so it would have been automatically depressed (this is how it makes sure a runaway process does not monopolize the system to the point it can't be killed). This email sent to site_archiver@lists.apple.com