Re: Idle priority
Re: Idle priority
- Subject: Re: Idle priority
- From: Terry Lambert <email@hidden>
- Date: Thu, 06 Aug 2009 09:31:17 -0700
Mike, you keep describing the problem you want to solve and how you
want to be able to solve it, but you aren't listening to me when I
tell you that you can solve it, but not the way you want to; having a
solution is more important than the how.
On top of that, your experimental "representative load" processes fit
in one L1 cache line and repeatedly bang on a single CPU register,
which is a really naieve experimental setup. So you get degenerate
case scheduler behaviour for "load" on any system without explicit
"idprio" support to partition it, and then wonder why.
You want a scheduler decision like:
IF !(a OR b OR ...)THEN z
You can't have that. You can have:
IF a THEN a ELSE IF !(b or ...) THEN z
And I even pointed you at the API documentation to do it. Plenty of
professional video, audio, rendering, and other tools on Mac OS X work
perfectly within that context.
But you are unwilling to play with the priority of 'a' (thereby
promising the system that 'a' is not a runaway process - which your
"load" code in fact IS) to get it. Fine.
As far as I'm concerned, the thread is over.
If you want a FreeBSD-like "idprio", file a /bug/enhancement request/
requesting it.
Regards,
-- Terry
On Aug 6, 2009, at 7:50 AM, Mike Mimic <email@hidden> wrote:
Hi!
--- On Thu, 8/6/09, Terry Lambert <email@hidden> wrote:
I think so. You have never explained your test set up
well enough that it could be reproduced.
I have been running those two programs I have given source code on a
8 cores system. Where in the first case I have ran (and measure) 8
"load" processes and in the second case I have run 8 "idle"
processes first, left them running and then ran (and measure) 8
"load" processes again.
Those 8 "load" processes represent normal load on my system for
which I do not want to have any slowdown and those 8 "idle"
processes processes represent computations I would like to run only
on space CPU cycles.
So the question is then how to make/program/configure those "idle"
processes in such way that they would run only on space CPU cycles
and do not slowdown my normal processes on a system I am running as
an user. I have tried both nice and setting thread priority but I
was not successful in that. So then this is impossible on Mac OS X?
Or am I doing something wrong?
And increasing priority of every other normal processes on my system
should not be required. I would like that they compete between
themselves normally. As they have been doing before. I just want to
run additional 8 processes on this system which would run only when
there would be some spare CPU cycles. And I want to flag those 8
processes as special in the sense that it does not matter for me if
they do not get any CPU cycles for few hours or days or years - but
that they get any and only spare CPU cycle that are available. And I
do not want that scheduler would give them non-idle CPU cycles
because my other normal processes would be CPU bound and thus
subject to a priority decay. Their priority can be decreased among
other normal processes but those "idle" processes should be always
using just idle CPU cycles.
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").
No, I am naming "idle" processes instances of my "idle" program I
was using in my test case(s) for which I would like to have the
behavior described above (that they would use only idle CPU cycles).
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.
No, using your example, I was running 4 identical processes, not 3,
thus it is normal that 4 identical processes *with same priority*
running on a 2 CPU system take 20 seconds instead of 10 seconds. If
I continue with your example, I was running two processes in the
background (on idle cycles, at least this I wish for) and then I ran
two additional processes and measure their user time. Alas, they ran
for for 20 seconds instead of 10 seconds which they would if those
background processes would cease getting CPU cycles (as during the
period of running those additional processes there would be no idle
cycles available).
So it is not that my "idle" processes kicked my "load" processes off
CPUs completely as my "idle" processes were running all the time in
the background (not just 10 seconds) thus my "load" processes would
never finish (or would take a lot lot more time to finish) if your
explanation would be the case.
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.
You must have mixed me with Jonas Maebe. He pointed out an example
using top and percentages. I used time program to measure my
examples. I ran them 10 times to get good results. And mean and
standard deviation values are showing that measurements are stable
enough to be able to conclude something from them. I agree that time
program is a lot more general than shark but the results it gives
about how long a process have been running in real and CPU time are
good enough to show that my "load" processes have been slowed down.
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.
I do not mind priority decay of my normal processes if they are CPU
bounded to give other normal processes some more CPU time (so that
user can still use a system). I would just like to run some
additional "idle" processes which would kick in only and always
where there would be any spare CPU cycles.
That normal processes would decay so much that the "idle" processes
would be able to kick in is something which should not happen as I
am (or would like to) specially declare my "idle" processes to run
only on spare CPU cycles.
Mike
_______________________________________________
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