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

On Fri, 28 Feb 2003, Andrew Morton wrote:
> >
> > Andrew, if you drop this patch, your X desktop usability drops?
> hm, you're right. It's still really bad. I forgot that I was using distcc.
> And I also forgot that tbench starves everything else only on CONFIG_SMP=n.
> That problem remains with us as well.

Andrew, I always thought that the scheduler interactivity was bogus, since
it didn't give any bonus to processes that _help_ interactive users
(notably the X server, but it could be other things).

To fix that, some people nice up their X servers, which has its own set of

How about something more like this (yeah, untested, but you get the idea):
the person who wakes up an interactive task gets the interactivity bonus
if the interactive task is already maxed out. I dunno how well this plays
with the X server, but assuming most clients use UNIX domain sockets, the
wake-ups _should_ be synchronous, so it should work well to say "waker
gets bonus".

This should result in:

- if X ends up using all of its time to handle clients, obviously X will
not count as interactive on its own. HOWEVER, if an xterm or something
gets an X event, the fact that the xterm has been idle means that _it_
gets a interactivity boost at wakeup.

- after a few such boosts (or assuming lots of idleness of xterm), the
process that caused the wakeup (ie the X server) will get the
"extraneous interactivity".

This all depends on whether the unix domain socket code runs in bottom
half or process context. If it runs in bottom half context we're screwed,
I haven't checked.

Does this make any difference for you? I don't know what your load test
is, and considering that my regular desktop has 4 fast CPU's I doubt I can
see the effect very clearly anyway ("Awww, poor Linus!")

NOTE! This doesn't help a "chain" of interactive helpers. It could be
extended to that, by just allowing the waker to "steal" interactivity
points from a sleeping process, but then we'd need to start being careful
about fairness and in particular we'd have to disallow this for signal


===== kernel/sched.c 1.161 vs edited =====
--- 1.161/kernel/sched.c Thu Feb 20 20:33:52 2003
+++ edited/kernel/sched.c Wed Mar 5 19:09:45 2003
@@ -337,8 +337,15 @@
* boost gets as well.
p->sleep_avg += sleep_time;
- if (p->sleep_avg > MAX_SLEEP_AVG)
+ if (p->sleep_avg > MAX_SLEEP_AVG) {
+ int ticks = p->sleep_avg - MAX_SLEEP_AVG + current->sleep_avg;
p->sleep_avg = MAX_SLEEP_AVG;
+ if (ticks > MAX_SLEEP_AVG)
+ ticks = MAX_SLEEP_AVG;
+ if (!in_interrupt())
+ current->sleep_avg = ticks;
+ }
p->prio = effective_prio(p);
enqueue_task(p, array);
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.163 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site