Re: Yielding the processor in a kext?
Re: Yielding the processor in a kext?
- Subject: Re: Yielding the processor in a kext?
- From: Anton Altaparmakov <email@hidden>
- Date: Fri, 7 Sep 2007 09:08:52 +0100
Hi,
On 7 Sep 2007, at 03:55, Michael Smith wrote:
On Sep 6, 2007, at 5:03 PM, Régis Duchesne wrote:
Is there a way to make the current thread yield the processor in a
kext?
Not in the fashion you describe. If you have work, do it. If the
scheduler has more important work that has to be done, it will take
the CPU away from your thread.
But for example from a file system kext we don't know what priority
the thread is and we don't own the thread either so we should not be
messing with priorities...
And what if we have work to do but can't do it because we need
another thread to do work first? It is stupid to hang onto our time
slice in at this point...
I understand that by default threads executing in the kernel are
pre-emptable, but sometimes I would like the current thread to
explicitly give the scheduler a chance to schedule another thread,
before the current thread's timeslice has elapsed. I'm looking for
something similar to cond_resched() on Linux.
The only reason to want to do this is if you are performing a long-
running low priority task on the wrong (high-priority) thread.
Don't do that. Do the work on a thread whose priority reflects the
true priority of the task. It's not your business to make
scheduling decisions; don't even try.
Your view is too limited. This is not true at all. I will give you
a concrete example of when I would like to yield the CPU from my file
system kext:
I need to take a lock but I can't do it safely because of holding
other locks so I do a try-lock. The try-lock fails so I have to drop
my locks and try again. It is totally brain damaged to try again
immediately. It would be far more sensible to yield the CPU to give
the other process holding my lock to finish its work and release it
and when the scheduler next gets to my process for me to try again
and if I fail again to yield again, etc... And trying again
immediately is actually MUCH worse than the fact that CPU is just
being burned unnecessarily because the other process might be trying
to take the lock I just dropped so if I take it again immediately the
chances of the other process taking that lock successfully and hence
making progress thus releasing both locks so my process can make
progress are close to zero at this point! )-:
And another example: In a critical path when a memory allocation
fails, I want to yield the CPU and try again later when the system
hopefully has more memory available as failing the allocation is a
disaster for file system consistency at this point. At the moment I
just do it in a busy loop trying again and again and again till the
scheduler decides to reschedule me. That's got to be totally
insane... )-:
I would very much like to know how I can tell the scheduler "I am
done, hand CPU to someone else now"...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
_______________________________________________
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