August 2009 - Darwin-kernel

Re: Kernel panics even in OSMalloc_noblock() while holding a spinlock
by Terry Lambert 08 Aug '09

08 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel panics even in OSMalloc_noblock() while holding a spinlock
by Michael Smith 08 Aug '09

08 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel panics even in OSMalloc_noblock() while holding a spinlock
by shailesh jain 08 Aug '09

08 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=52akB4NSjFyMVYydD/6t0zIAzNF/PV8QbWmh3uNJ+vk=; b=THksjdnp5WRuU+Nmv1MDzLTWV/67tOcnbP8rtcg/xfVYmjqd8HYm0JWYz3bczS3RnC z1NRY7+l8YgcWH3LnMSMRcPswXze1r+gqQwnp2V0I1r0quAONyBGmPvAy2hnPo4K1vsA Mc3hH0OE6+u80Sq3UQT8cZc8fHOv5ZaGkBmb4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=asMzUAERDAwh63E+pGLudWHyoxpnVACVqwDAcy0+yBcx3xABeWeihjxclw8K7qgqHr BcvVGokh4gVkoZB6NXvSk20MHmEZrL0fw6IL/WZjs0bY0mD1LiUAZUXlR68a/e3xbpvq aw/4UbO5Z59EG1Q4dyoVKSmrgb2rli5HTCkPc= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel panics even in OSMalloc_noblock() while holding a spinlock
by Terry Lambert 08 Aug '09

08 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello there - void alloc_thread(void *arg) { lck_spin_t* mylock; // ... initialize lock lck_spin_lock(mylock); [ ... ] Yes. You are missing several things... -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Aug 7, 2009, at 3:50 PM, Eric Ogren wrote: I am working on a kernel extension that sometimes attempts to allocate memory while holding a spinlock (lck_spin_t). I've read in several postings to this list that doing so while OSMalloc can cause a kernel panic, and that developers should instead use OSMalloc_noblock() and be prepared to deal with a NULL result. However, I am seeing kernel panics even when calling the noblock variant. The panic is occurring inside zalloc_canblock() at the lock_zone() call, which is indeed trying to block. This problem is very easily reproducible with a simple kext that spawns 2 threads with the following thread routine: while (true) { void* foo = OSMalloc_noblock(8, tag); // tag is a global variable initialized in the start function } } Loading the kext panics the system almost immediately with the following stack, which is the same as the stack as I come across in the occasional panics: #2 0x0012b4c6 in panic (str=0x1 <Address 0x1 out of bounds>) at / SourceCache/xnu/xnu-1228.12.14/osfmk/kern/debug.c:275 #3 0x001368fd in thread_invoke (self=0x43018b8, thread=0x39a7c80, reason=0) at /SourceCache/xnu/xnu-1228.12.14/osfmk/kern/sched_prim.c: 1477 Am I missing something here, or is it unsafe to even call OSMalloc_noblock() while holding a spinlock? If I look at the source code for zalloc, lock/unlock_zone() is always called regardless of the canblock parameter, and that zone lock is indeed a mutex. Seems almost like the canblock parameter just means that the calling thread will not block for a long time (ie will not try to refill or garbage collect the zone if it's full), not that it will never block at all. (A) You're in a tight while/true loop allocating all of kernel memory a tiny bit at a time until you exhaust it, which is known to cause a panic. (B) An infinite loop is too long a time to hold a spinlock; holding a spinlock too long is known to cause a panic (C) You're missing your paste of at least the lines above the portion of the backtrace you quoted (which is cut off at frame #2), which would include the actual panic message and frame #1 so that we could see if the panic was related to holding a spinlock or related to you exhausting the zone of zones, or running the wrong version of Parallels or dereferencing a NULL pointer, or some other known cause of panics, or some other unknown cause of panics. (D) You have already been told you can use Djikstra's algorithm, in which you speculatively do an allocation before holding the spinlock, and if you use it, fine, mark it as consumed at the point you would have done your allocation, and if you don't, fine, free it after you have dropped your spinlock, no harm no foul, no allocation or free inside a spinlock This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel panics even in OSMalloc_noblock() while holding a spinlock
by Michael Smith 08 Aug '09

08 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Kernel panics even in OSMalloc_noblock() while holding a spinlock
by Eric Ogren 07 Aug '09

07 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=DRsbt0ldcgeQ/rHo/pgvFk3krgMkf3EjUpMNPIXGJjw=; b=s+D+kf4XXl4aNFlTqIZq5Hy6k1TXSM3b+PzciXhZqXDlnEKXr/cdHzjVvkZP9Di2F6 uJWbT85rSLiyafgRGb8ZpnBjxpcTO9+rf8RlkQf/yfYrr5KFgRJpVXAL0S3wUnpaW2gb dtZnwH9s6ZhzfqYrqio2JjG5Vze2zgcTkBqrY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=Y06OBoFMntB6H/bkq64NwvsnbvrYC/ien2UP2ms6SMAtrT4Hgha/5WvdsaY6vK9j8q tUaeH/2b7yHiblECQBF7yMCUkEqN76wWzfxMuyX6B32+nmKOi6uta7fwAp51vQbnDytR +H2fynJ0CDmddS6avLeKUMvz1Z+mI+f5BQaKQ= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Idle priority
by Terry Lambert 06 Aug '09

06 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com 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 As far as I'm concerned, the thread is over. Regards, -- Terry Hi! I think so. You have never explained your test set up well enough that it could be reproduced. 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"). 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, 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. 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. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… 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. 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. If you want a FreeBSD-like "idprio", file a /bug/enhancement request/ requesting it. On Aug 6, 2009, at 7:50 AM, Mike Mimic <ppagee(a)yahoo.com> wrote: --- On Thu, 8/6/09, Terry Lambert <tlambert(a)apple.com> wrote: 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. 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). 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. 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. 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 This email sent to site_archiver(a)lists.apple.com

1 0

Re: Idle priority
by Mike Mimic 06 Aug '09

06 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1249570209; bh=1XP0x+JDrEoV7aT4lozgcdf11VGl++d5r+pQGKdIdDg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4CxfZwi3lBg/lPW8vLeuGencs9iGpv854G2J5fiSt6moPeM96tgiPFhHlkAo11T09c/E/EAkfEcv+UhylyU5BdQ4L/I5R1pO+53FKal3fX2XqftLk7THbaCETCefIA9zPc4+y1Ng5i9s9uLJfB3h8xnEjUpgS+uam3b4pEUnvnI= Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OnrhloMqCO/fxjFoL38uxt9Wn60j8nQxeWdaEqQtopZ/f41+URzSVqZOmZDnd+gb5IF9YkOc8BbZJpYPDSB9IWtjo04YLToZcnXYLCuqx+ahurBnbg7IYG2eFvWgbxJGIv4NAT+3yQfW04KHpCcy5CvJOQhOuXrwDPHTVkLRJZ8=; Hi! --- On Thu, 8/6/09, Terry Lambert <tlambert(a)apple.com> 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 (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: virtual memory limit
by Roger Herikstad 06 Aug '09

06 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=c48+a3dks406VkuTeVwNdEsSuez+tqqAo7bj1Xf0u7o=; b=p/UCyNOd/9/H2m1oHgHJ6Ex3WbbPKAGyRRjhZcceFa0uzbnk2lRb5BK3I0htiRARSs bQTN4tPkarLF+sDj3hymYBeAwaU2D6t9eWfEq1+IjzBiJ7nCBNu4VHgocGcrSYT9tjvM uHJ/99Jk/91HgzcI9GwIQFodDxWFYx/vBVVNk= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AI5HeTzkyY4r/XC7sPyX/Ri2VQJlAH9l+4duHEjFMOszwalqqcB39dAfeG7T2gWRkv HTYYtO8I6LiqaQ53h+8kLFgF/Jq+p4lDKLzJ53IcvImAiOmUMkHncOy/ouvOrz/Fvpj0 q9MjbU5rPA9//9ZRuwlfVK7s2mt6R9fH+ZeKM= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Idle priority
by Terry Lambert 05 Aug '09

05 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Aug 5, 2009, at 2:50 PM, Mike Mimic wrote: --- On Wed, 8/5/09, Terry Lambert <tlambert(a)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(a)lists.apple.com

1 0