lkml.org 
[lkml]   [1997]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: stress testing and loadavg
Date
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

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.574 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site