[lkml]   [2003]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] "HT scheduler", sched-2.5.63-B3

On 6 Mar 2003, Alan Cox wrote:
> X isnt special at all. Research OS people have done stuff like time transfers
> but I've not seen that in a production OS. In that situation an interactive
> task blocking on a server hands on some of its interactiveness to whoever
> services the request.

This is what I really wanted to do - give the interactivity away at
blocking time. However, there's usually no sane way to do that, since we
don't know a-priori who we are blocking _for_. We could try to transfer it
in the unix domain socket sleep case to whoever is waiting at the other
end, but that's actually quite complex and ends up having each sleep entry
somehow inform the subsystem it is sleeping on that it wants to give
interactivity to the other end.

The thing about wakeups is that it's an "illogical" place to give the
bonus ("it's too late to give the server a bonus _now_, I wanted it when I
went to sleep"), but it's the _trivial_ place to give it.

It also (I'm convinced) is actually in the end exactly equivalent to
giving the bonus at sleep time - in the steady state picture. In the
single-transfer case it is wrong, but the single transfer case doesn't
matter - the interactivity bonus isn't a "immediate shot of caffeine into
the bloodstream" anyway. The interactivity bonus is supposed to help over
time, so the only thing that matters is really the steady state.

But the proof is in the pudding. Does this actually make things appear
"nicer" to people? Or is it just another wanking session?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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