On Thu, 17 Jul 2003, Con Kolivas wrote:
> O*int patches trying to improve the interactivity of the 2.5/6 scheduler for
> desktops. It appears possible to do this without moving to nanosecond
> resolution.
>
> This one makes a massive difference... Please test this to death.
>
> Changes:
> The big change is in the way sleep_avg is incremented. Any amount of sleep
> will now raise you by at least one priority with each wakeup. This causes
> massive differences to startup time, extremely rapid conversion to interactive
> state, and recovery from non-interactive state rapidly as well (prevents X
> stalling after thrashing around under high loads for many seconds).
>
> The sleep buffer was dropped to just 10ms. This has the effect of causing mild
> round robinning of very interactive tasks if they run for more than 10ms. The
> requeuing was changed from (unlikely()) to an ordinary if.. branch as this
> will be hit much more now.
Con, I'll make a few notes on the code and a final comment.
> -#define MAX_BONUS ((MAX_USER_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100)
> +#define MAX_BONUS (40 * PRIO_BONUS_RATIO / 100)
Why did you bolt in the 40 value ? It really comes from (MAX_USER_PRIO - MAX_RT_PRIO)
and you will have another place to change if the number of slots will
change. If you want to clarify better, stick a comment.
> + p->sleep_avg = (p->sleep_avg * MAX_BONUS / runtime + 1) * runtime / MAX_BONUS;
I don't have the full code so I cannot see what "runtime" is, but if
"runtime" is the time the task ran, this is :
p->sleep_avg ~= p->sleep_avg + runtime / MAX_BONUS;
(in any case a non-decreasing function of "runtime" )
Are you sure you want to reward tasks that actually ran more ?
Con, you cannot follow the XMMS thingy otherwise you'll end up bolting in
the XMMS sleep->burn pattern and you'll probably break the make-j+RealPlay
for example. MultiMedia players are really tricky since they require strict
timings and forces you to create a special super-interactive treatment
inside the code. Interactivity in my box running moderate high loads is
very good for my desktop use. Maybe audio will skip here (didn't try) but
I believe that following the fix-XMMS thingy is really bad. I believe we
should try to make the desktop to feel interactive with human tollerances
and not with strict timings like MM apps. If the audio skips when dragging
like crazy a X window using the filled mode on a slow CPU, we shouldn't be
much worried about it for example. If audio skip when hitting the refresh
button of Mozilla, then yes it should be fixed. And the more you add super
interactive patterns, the more the scheduler will be exploitable. I
recommend you after doing changes to get this :
http://www.xmailserver.org/linux-patches/irman2.c
and run it with different -n (number of tasks) and -b (CPU burn ms time).
At the same time try to build a kernel for example. Then you will realize
that interactivity is not the bigger problem that the scheduler has right
now.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:27 EST