Re: Idle priority
Re: Idle priority
- Subject: Re: Idle priority
- From: Terry Lambert <email@hidden>
- Date: Thu, 30 Jul 2009 02:59:50 -0700
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.
-- Terry
On Jul 30, 2009, at 2:33 AM, Terry Lambert <email@hidden> wrote:
On Jul 30, 2009, at 1:05 AM, Jonas Maebe <email@hidden>
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden