[sched] [patch] interactiveness-improvements-2.5.3-pre2-A0

From: Ingo Molnar (mingo@elte.hu)
Date: Sun Jan 20 2002 - 08:51:41 EST


the attached patch cleans up and improves the interactiveness code in
2.5.3-pre2 further. It's the interactiveness code from -J2 that got good
interactiveness feedback.

the patch changes three aspects of interactiveness:

1) the bonus/penalty of SCHED_OTHER tasks has been reduced by 10%, from
   [-20 ... +20] to [ -18 ... +19 ]. The reason is two-fold:

        - protect nice -20 interactive tasks from default-nicelevel
          interactive tasks. This improves audio playback quality, making
          nice -20 a more protected priority domain.

        - protect default-nicelevel CPU hogs from nice +19 CPU hogs. This
          means that nice +19 SETI jobs will not distrupt the timeslices
          of normal kernel compilation jobs.

2) improve the definition of TASK_INTERACTIVE:

       - the bottom 25% of the priority range is for 'unconditionally
         interactive tasks'.

       - the top 25% of the priority range is for 'unconditionally CPU-hog
         tasks'

       - the middle 50% is for 'conditionally interactive' tasks.
         Interactivity depends on whether a task has 'won' at least 3
         priority levels due to being interactive, relative to its default
         priority level.

this change has the following effect: tasks with negative nice values it's
easier to be interactive, and harder to become rated as CPU hogs. For
tasks with positive nice values it's much harder to become rated as
interactive, and easy to be rated as CPU hogs. Tasks on the default
nice-level have none of the 'prejudice' ratings, it depends on its actual
bonus whether it's rated as interactive or not.

3) newly forked children lose 20% of their parent's priority and sleep
   average.

this change has a positive effect on starting xterms during high-load
situations. The process that starts the xterm is usually a heavily
interactive task. But the first xterm process often fork()s a second
process, which was penalized too heavily in the previous fork_wakeup code,
causing that process to get into the 'CPU-bound hell', causing massive
delays of xterm startups. This rule is a purely experimental value, but it
expresses the basic concept correctly as well: we want children to get
some of the benefits of their parents, but we also want them to not get
*all* of the benefits, and work to achieve their own bonuses.

        Ingo



-
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 Jan 23 2002 - 21:00:37 EST