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: Sat, 8 Sep 2007 01:33:03 +0100
Hi Régis,
On 8 Sep 2007, at 00:41, Régis Duchesne wrote:
Indeed, sched_yield() calls the swtch_pri() system call with zero as
only argument (the argument is not used by swtch_pri() so it does not
matter anyway). That in turn is connected to thread_block_reason()
which you cannot call form a kext but that is called from
thread_block()
which I suggested to you in my previous email so my answer of using
thread_block(THREAD_CONTINUE_NULL) may well turn out to be a
winner here!
I did the same investigation, but came to a different conclusion:
swtch_pri actually uses thread_block_reason(THREAD_CONTINUE_NULL,
NULL,
AST_YIELD) and the only difference is that:
1) thread_block_reason is not exported
2) AST_YIELD forces the timeslice of the current thread to 0
So by just using thread_block(), we might not surrender the timeslice.
I'll do some more real-life testing.
Correct but due to 1) it is irrelevant as I cannot see any way to
specify AST_YIELD from a kext (I am assuming you will not manage to
get Apple to export thread_block_reason()) and as to 2) I am not
convinced it matters. Looking at the code, thread_select() only
cares about the timeslice value (which is the only thing set to zero
by AST_YIELD) when the current process priority is at REALTIME so
that is not an issue (unless your threads run realtime I suppose but
I am assuming here that they are not). Further choose_thread() does
not care about the timeslice at all. It unconditionally switches to
the next thread in the run queue even going to the trouble of
stealing a task from a different CPU run queue if needed.
So perhaps what actually happens is that calling with AST_YIELD kills
the current time slice and starts a new one whereas AST_NONE (used by
thread_block()) hands the remainder of the current time slice to a
new thread.
Again, please take what I say with a pinch of salt as I am not
exactly an OSX scheduler expert having never looked at the code
before this evening!
But yes, real-life testing will show what it really does. (-:
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