Re: Idle priority
Re: Idle priority
- Subject: Re: Idle priority
- From: Terry Lambert <email@hidden>
- Date: Wed, 5 Aug 2009 16:37:47 -0700
On Aug 5, 2009, at 2:50 PM, Mike Mimic wrote:
--- On Wed, 8/5/09, Terry Lambert <email@hidden> wrote:
I will point out that the reported real time on the second
one is very close to 20.0722, double the CPU time, which
implied that it didn't actually get any CPU time until the
competing (non-idle priority) process finished, which is
what you were appeared to be asking to have happen.
I think you misunderstood the results or I have presented them
badly. I have been measuring twice "load" program which represents
my normal load for which I do not want to have any slowdown while I
run my "idle" program in the background on the idle priority.
I think so. You have never explained your test set up well enough
that it could be reproduced. This is one of the reasons I suggested
that if you felt there was still a problem, you need to file a bug
report and attach the necessary code to reproduce it.
And no, please do not send me a disk image; if you want to, file a bug
report and attach it to that.
But results show that there is slowdown. In fact the slowdown is
around 100% (real time is 20 seconds instead of 10 seconds) what
shows that the "idle" processes have probably not been ran under any
decreased priority whatsoever (like my example with nice previous
time which showed slight decrease, but still no idle priority
decrease).
So proper behavior (as I see it) would be that in both cases my
"load" processes would take 10 seconds to complete. Whether there
are "idle" processes running (the second case) or not (the first
case).
I think you are confusing "idle" (the process which runs the power
management code, come hell or high water, and which runs at "idle
priority") with "idle" (the CPU not having any other work to do, so
it, on FreeBSD, would otherwise do an STI ; HLT, if you hadn't given
it work to do at FreeBSD "idprio").
Mike and I both told you to stay away from the bottom level system
priorities. You didn't. Now you are seeing why.
The fact that both are CPU bound and should have taken ~10 seconds of
user time and, for 3 identical processes on a 2 CPU system, 15 seconds
of wall time, and you saw it taking 20 seconds of wall time indicates
you successfully wrote a program which can kick your other program off
a CPU completely.
To get actual time-on-cpu on a per-process basis you'd need
to examine the thread state structure before the thread
exits. This is why I suggested you use shark to gather
the information, back when this thread started.
I doubt that this difference (10 seconds) is the case of me using
time instead of Shark.
No, but your other percentage numbers earlier were instantaneous
samples made at one second intervals having to do with whether a
particular process was "on cpu" or "off cpu" at the time the sample
got run. The percentages of CPU time you were posting were
effectively meaningless because they were statistical rather than non-
statistical. If you don't feel like that is OK, file a bug against
"top".
For what you want, you need to both depress the default priority of
your "idle" process AND you need to escalate the default priority of
your normal ("non-idle") workload, or, being CPU intensive, it will be
subject to an effective priority decay as the system attempts to
ensure fairness and user responsiveness to a human attached to the
system by a keyboard, mouse, and monitor. Maybe a human trying to
kill a runaway process. There is no other way to prevent effective
priority decay of CPU bound processes.
-- 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