site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -- 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 1:05 AM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote: On 30 Jul 2009, at 06:41, Michael Smith wrote: Or this task should only be run if the system has absolutely NOTHING else (other than other tasks of the same priority) to do. That's what the minimum regular priority is for. The system reserves the right to decide that something else is even less important. You're making the usual mistake of thinking that your process is somehow special, although in this case that it's somehow less important than other unimportant things. Mark it as not interesting, then let the system decide what to do about it. 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? 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. 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. This email sent to site_archiver@lists.apple.com