site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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. 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. -- 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 Aug 5, 2009, at 2:50 PM, Mike Mimic wrote: --- On Wed, 8/5/09, Terry Lambert <tlambert@apple.com> wrote: 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. 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. This email sent to site_archiver@lists.apple.com