On Tue, 5 Aug 1997, Ingo Molnar wrote:
> the only heuristics i think would be useful, is to give _human sourced
> interrupts_ some 'priority quantum', which they carry and transfer to
> processes ;) This would be attached to my keyboard and my mouse ;) We now
> get the same effect in a very indirect way: human interrupts are by nature
> very long-intervalled, thus processes depending on these interrupts and
> doing short action are able to accumulate dynamic priority usually. Also,
> NT's 'foreground priority' concept is an alternative (but quite broken ;)
> way to provide the same effect.
Rather than "accumulate dynamic priority", as the current scheduler
does, I've always thought that "sleep priorities" are a better scheme.
When a task calls sleep()/sleep_on()/_interruptible_sleep_on()/etc,
it would pass an extra parameter which is the priority used [for the task]
when it is woken up.
This would allow tasks which are sleeping while holding valuable
resources to be given a high priority. They would get onto a processors
very quickly [after being woken up], so they could complete their action
and release the resources. A good example of this is the block-device
requests structures. When these are all in use, a task blocks waiting for
one to become free. While blocking, it is holding buffers and maybe
locking pages. For the keyboard driver, keyboard_wait_for_keypress()
would use a high sleep priority on the 'keypress_wait' queue.
Although ugly, it is also possible to have sleep_on() [and friends] look
at the context of the task which is sleeping and raise the sleep-priority
for certain users/controlling-tty. (I told you it was ugly!).
Regards,
markhe
------------------------------------------------------------------
Mark Hemment, Unix/C Software Engineer (Contractor)
markhe@nextd.demon.co.uk http://www.nextd.demon.co.uk/
"Success has many fathers, failure is a B**TARD!" - anon
------------------------------------------------------------------