Messages in this thread | | | From | Malcolm Beattie <> | Subject | Re: stress testing and loadavg | Date | Thu, 7 Aug 1997 12:00:07 +0100 (BST) |
| |
Mark Hemment writes: > 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 got me thinking about continuations, where a blocking sleep just before a return to user mode would specify a function to call (without running in the task's context and hence fast). This has been discussed before, I think, and it wasn't thought to be worth it.
That's led me to another thought though: the sleep_on could specify a function(+argument) to be called at wake_up time. The advantage that the function is called without having to schedule the task is still kept but there's no disavantage of complexity or code shuffling as there is for getting the call_continuation pushed to the end of the function that sleeps. A task that wanted to be awoken with high priority would do something like
static void raise_priority(void *task) { ((struct task_struct *)task)->priority += delta; } sleep_on_plus(&foo_wait, raise_priority, current);
and wake_up would be changed to do the callback where necessary. Since the callback is done in the context of the task doing the wake_up there's no delay between wake_up and when the task is finally scheduled and I can imagine that being rather useful. It would need to be done without increasing the overhead of wake_up unacceptably. Currently, wake_up does
if ((p->state == TASK_UNINTERRUPTIBLE) || (p->state == TASK_INTERRUPTIBLE)) wake_up_process(p);
so could there possibly be another TASK_INTERRUPTIBLE_PLUS_CALLBACK state or maybe have a bitmask instead if (p->state & TASK_WAITING) ... or is there some other way of checking for the existence of a callback request cheaply? Quite a lot of kernel code already "knows" about TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE but almost all of that is simply setting the current->state which would continue to work anyway.
--Malcolm
-- Malcolm Beattie <mbeattie@sable.ox.ac.uk> Unix Systems Programmer Oxford University Computing Services
| |