Re: Yielding the processor in a kext?
Re: Yielding the processor in a kext?
- Subject: Re: Yielding the processor in a kext?
- From: Terry Lambert <email@hidden>
- Date: Fri, 7 Sep 2007 19:50:17 -0700
On Sep 7, 2007, at 9:59 AM, Régis Duchesne wrote:
Michael Smith wrote:
It's not your business to make scheduling
decisions; don't even try.
That is just not true. In the example I gave in my previous email, I
show that sometimes, the application knows better than the OS how
things
must be scheduled.
It does not matter how much progress all my threads make compared to
the
rest of the system, but it does matter how much progress they make
relative to each other.
In other words, I'm trying to write my own little scheduler (just for
all the threads within my task), on top (not instead of) the xnu
system-wide scheduler. I'm the only one who can do that because xnu
obviously doesn't know the specifics of my application.
Your scheduler should be a "work-to-do" cooperative multitasking
scheduler, with your large thread pool scheduled onto a smaller set of
real backing threads to do the work.
This would allow you to queue up work units and manage "number of work
units per thread" as a figure of merit on your own work queues.
Terry Lambert wrote:
You block on the mutex held by the other thread
Well that does not work in my case either: as I explained, I don't
want
to stop the thread that is too far ahead in the computation. I just
want
to slow it down. So blocking is not an option.
Do not move it from your implementation of the "too many work units
completed" to your implementation of "needs to complete more work
units now" queues so that when an idle backing thread becomes
available and takes the next item of your "needs to complete more work
units now", it won't see the object.
I want to hint the scheduler that "hey, you made me run, but at the
app
level I know that it is better if I do nothing at this moment, so I
would like to voluntarily relinquish my time slice."
Actually, you want to control the scheduler queue order, which you are
not permitted to do. What you _are_ permitted to do is abstract the
system scheduler from your workload using your own queues and a finite
state automata, effectively implementing "scope=my_task "
prioritization of threads within your task.
-- Terry _______________________________________________
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