site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -- Terry On Jul 30, 2009, at 2:33 AM, Terry Lambert <tlambert@apple.com> wrote: _______________________________________________ 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... Hmmm... It looks like the dnetc client is started from an icon and has at least rudimentary GUI input (cmd-Q to quit). This means it is a GUI CFRunLoop app and at least the GUI thread will therefore be RT, and will be polled by the window server with AppleEvent messages to show/ not show the "not responding" cursor. One way to fix this would be to at least put most of its guts into a vanilla command line app, and for users to avoid using a separate very small GUI app for starting/stopping (the small app would have the same issue). A launchd job would be preferrable, with a separate preferences panel, if GUI control was absolutely necessary. Also, if your distributed application facility has a characteristic process, it looks like the dnetc client also supports a "pause if running" facility intended to overcome just such a problem. But the first step would be to fix their client via partitioning of functionality. 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. -- Terry This email sent to site_archiver@lists.apple.com