[QUESTION] 2.4.x nice level

[QUESTION] 2.4.x nice level

[SodaPop]

I too have noticed that nicing processes does not work nearly as
effectively as I'd like it to.  I run on an underpowered machine,
and have had to stop running things such as seti because it steals too
much cpu time, even when maximally niced.

As an example, I can run mpg123 and a kernel build concurrently without
trouble; but if I add a single maximally niced seti process, mpg123 runs
out of gas and will start to skip while decoding.

Is there any way we can make nice levels stronger than they currently are
in 2.4?  Or is this perhaps a timeslice problem, where once seti gets cpu
time it runs longer than it should since it makes relatively few system
calls?

-dennis T

Re: [QUESTION] 2.4.x nice level

[george anzinger]

SodaPop wrote:
> 
> I too have noticed that nicing processes does not work nearly as
> effectively as I'd like it to.  I run on an underpowered machine,
> and have had to stop running things such as seti because it steals too
> much cpu time, even when maximally niced.
> 
> As an example, I can run mpg123 and a kernel build concurrently without
> trouble; but if I add a single maximally niced seti process, mpg123 runs
> out of gas and will start to skip while decoding.
> 
> Is there any way we can make nice levels stronger than they currently are
> in 2.4?  Or is this perhaps a timeslice problem, where once seti gets cpu
> time it runs longer than it should since it makes relatively few system
> calls?
> 
In kernel/sched.c for HZ < 200 an adjustment of nice to tick is set up
to be nice>>2 (i.e. nice /4).  This gives the ratio of nice to time
slice.  Adjustments are made to make the MOST nice yield 1 jiffy, so
using this scale and remembering nice ranges from -19 to 20 the least
nice is 40/4 or 10 ticks.  This implies that if only two tasks are
running and they are most and least niced then one will get 1/11 of the
processor, the other 10/11 (about 10% and 90%).  If one is niced and the
other is not you get 1 and 5 for the time slices or 1/6 and 5/6 (17% and
83%).  

In 2.2.x systems the full range of nice was used one to one to give 1
and 39 or 40 or 2.5% and 97.5% for max nice to min.  For most nice to
normal you would get 1 and 20 or 4.7% and 95.3%.

The comments say the objective is to come up with a time slice of 50ms,
presumably for the normal nice value of zero.  After translating the
range this would be a value of 20 and, yep 20/4 give 5 jiffies or 50
ms.  Sure puts a crimp in the min to max range, however.

George

Re: [QUESTION] 2.4.x nice level

[Rik van Riel]

On Mon, 9 Apr 2001, george anzinger wrote:
> SodaPop wrote:
> > 
> > I too have noticed that nicing processes does not work nearly as
> > effectively as I'd like it to.  I run on an underpowered machine,
> > and have had to stop running things such as seti because it steals too
> > much cpu time, even when maximally niced.

> In kernel/sched.c for HZ < 200 an adjustment of nice to tick is set up
> to be nice>>2 (i.e. nice /4).  This gives the ratio of nice to time
> slice.  Adjustments are made to make the MOST nice yield 1 jiffy, so
	[snip 2.4 nice scale is too limited]

I'll try to come up with a recalculation change that will make
this thing behave better, while still retaining the short time
slices for multiple normal-priority tasks and the cache footprint
schedule() and friends currently have...

[I've got some vague ideas ... give me a few hours to put them
into code ;)]

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

Re: [QUESTION] 2.4.x nice level

[george anzinger]

Rik van Riel wrote:
> 
> On Mon, 9 Apr 2001, george anzinger wrote:
> > SodaPop wrote:
> > >
> > > I too have noticed that nicing processes does not work nearly as
> > > effectively as I'd like it to.  I run on an underpowered machine,
> > > and have had to stop running things such as seti because it steals too
> > > much cpu time, even when maximally niced.
> 
> > In kernel/sched.c for HZ < 200 an adjustment of nice to tick is set up
> > to be nice>>2 (i.e. nice /4).  This gives the ratio of nice to time
> > slice.  Adjustments are made to make the MOST nice yield 1 jiffy, so
>         [snip 2.4 nice scale is too limited]
> 
> I'll try to come up with a recalculation change that will make
> this thing behave better, while still retaining the short time
> slices for multiple normal-priority tasks and the cache footprint
> schedule() and friends currently have...
> 
> [I've got some vague ideas ... give me a few hours to put them
> into code ;)]

You might check out this:

http://rtsched.sourceforge.net/

I did some work on leveling out the recalculation overhead.  I think, as
the code shows, that it can be done without dropping the run queue lock.

I wonder if the wave nature of the recalculation cycle is a problem.  By
this I mean after a recalculation tasks run for relatively long times
(50 ms today) but as the recalculation time approaches, the time reduces
to 10 ms.  Gets one to thinking about a way to come up with a more
uniform, over time, mix.

George

George

[test-PATCH] Re: [QUESTION] 2.4.x nice level

[Rik van Riel]

On Tue, 10 Apr 2001, Rik van Riel wrote:

> I'll try to come up with a recalculation change that will make
> this thing behave better, while still retaining the short time
> slices for multiple normal-priority tasks and the cache footprint
> schedule() and friends currently have...

OK, here it is. It's nothing like montavista's singing-dancing
scheduler patch that does all, just a really minimal change that
should stretch the nice levels to yield the following CPU usage:

Nice    0    5   10   15   19
%CPU  100   56   25    6    1

Note that the code doesn't change the actual scheduling code,
just the recalculation. Care has also been taken to not increase
the cache footprint of the scheduling and recalculation code.

I'd love to hear some test results from people who are interested
in wider nice levels. How does this run on your system?  Can you
trigger bad behaviour in any way?

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/



--- linux-2.4.3-ac4/kernel/sched.c.orig	Tue Apr 10 21:04:06 2001
+++ linux-2.4.3-ac4/kernel/sched.c	Wed Apr 11 06:18:46 2001
@@ -686,8 +686,26 @@
 		struct task_struct *p;
 		spin_unlock_irq(&runqueue_lock);
 		read_lock(&tasklist_lock);
-		for_each_task(p)
+		for_each_task(p) {
+		    if (p->nice <= 0) {
+			/* The normal case... */
 			p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice);
+		    } else {
+			/*
+			 * Niced tasks get less CPU less often, leading to
+			 * the following distribution of CPU time:
+			 *
+			 * Nice    0    5   10   15   19
+			 * %CPU  100   56   25    6    1	
+			 */
+			short prio = 20 - p->nice;
+			p->nice_calc += prio;
+			if (p->nice_calc >= 20) {
+			    p->nice_calc -= 20;
+			    p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice);
+			}
+		    }
+		}
 		read_unlock(&tasklist_lock);
 		spin_lock_irq(&runqueue_lock);
 	}
--- linux-2.4.3-ac4/include/linux/sched.h.orig	Tue Apr 10 21:04:13 2001
+++ linux-2.4.3-ac4/include/linux/sched.h	Wed Apr 11 06:26:47 2001
@@ -303,7 +303,8 @@
  * the goodness() loop in schedule().
  */
 	long counter;
-	long nice;
+	short nice_calc;
+	short nice;
 	unsigned long policy;
 	struct mm_struct *mm;
 	int has_cpu, processor;

Re: [test-PATCH] Re: [QUESTION] 2.4.x nice level

[Rik van Riel]

On Wed, 11 Apr 2001, Rik van Riel wrote:

> OK, here it is. It's nothing like montavista's singing-dancing
> scheduler patch that does all, just a really minimal change that
> should stretch the nice levels to yield the following CPU usage:
> 
> Nice    0    5   10   15   19
> %CPU  100   56   25    6    1

  PID USER     PRI  NI  SIZE SWAP  RSS SHARE STAT %CPU %MEM   TIME COMMAND
  980 riel      17   0   296    0  296   240 R    54.1  0.5  54:19 loop
 1005 riel      16   5   296    0  296   240 R N  27.0  0.5   0:34 loop
 1006 riel      17  10   296    0  296   240 R N  13.5  0.5   0:16 loop
 1007 riel      18  15   296    0  296   240 R N   4.5  0.5   0:05 loop
  987 riel      20  19   296    0  296   240 R N   0.4  0.5   0:25 loop

... is what I got when testing it here. It seems that nice levels
REALLY mean something with the patch applied ;)

You can get it at http://www.surriel.com/patches/2.4/2.4.3ac4-largenice

Since there seems to be quite a bit of demand for this feature,
please test it and try to make it break. If it doesn't break we
can try to put it in the kernel...

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

Re: [test-PATCH] Re: [QUESTION] 2.4.x nice level

[Pozsar Balazs]

On Wed, Apr 11, 2001 at 12:53:16PM -0300, Rik van Riel wrote:
> On Wed, 11 Apr 2001, Rik van Riel wrote:
> 
> > OK, here it is. It's nothing like montavista's singing-dancing
> > scheduler patch that does all, just a really minimal change that
> > should stretch the nice levels to yield the following CPU usage:
> > 
> > Nice    0    5   10   15   19
> > %CPU  100   56   25    6    1
> 
>   PID USER     PRI  NI  SIZE SWAP  RSS SHARE STAT %CPU %MEM   TIME COMMAND
>   980 riel      17   0   296    0  296   240 R    54.1  0.5  54:19 loop
>  1005 riel      16   5   296    0  296   240 R N  27.0  0.5   0:34 loop
>  1006 riel      17  10   296    0  296   240 R N  13.5  0.5   0:16 loop
>  1007 riel      18  15   296    0  296   240 R N   4.5  0.5   0:05 loop
>   987 riel      20  19   296    0  296   240 R N   0.4  0.5   0:25 loop

How does this scale to negative nice levels? Afaik it should, in some way.
(I don't mean that it's wrong in this state, i'm just asking).

regards,
Balazs.

Re: [test-PATCH] Re: [QUESTION] 2.4.x nice level

[george anzinger]

One rule of optimization is to move any code you can outside the loop. 
Why isn't the nice_to_ticks calculation done when nice is changed
instead of EVERY recalc.?  I guess another way to ask this is, who needs
to see the original nice?  Would it be worth another task_struct entry
to move this calculation out of the loop?

George

Rik van Riel wrote:
> 
> On Tue, 10 Apr 2001, Rik van Riel wrote:
> 
> > I'll try to come up with a recalculation change that will make
> > this thing behave better, while still retaining the short time
> > slices for multiple normal-priority tasks and the cache footprint
> > schedule() and friends currently have...
> 
> OK, here it is. It's nothing like montavista's singing-dancing
> scheduler patch that does all, just a really minimal change that
> should stretch the nice levels to yield the following CPU usage:
> 
> Nice    0    5   10   15   19
> %CPU  100   56   25    6    1
> 
> Note that the code doesn't change the actual scheduling code,
> just the recalculation. Care has also been taken to not increase
> the cache footprint of the scheduling and recalculation code.
> 
> I'd love to hear some test results from people who are interested
> in wider nice levels. How does this run on your system?  Can you
> trigger bad behaviour in any way?
> 
> regards,
> 
> Rik
> --
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
> 
>                 http://www.surriel.com/
> http://www.conectiva.com/       http://distro.conectiva.com.br/
> 
> --- linux-2.4.3-ac4/kernel/sched.c.orig Tue Apr 10 21:04:06 2001
> +++ linux-2.4.3-ac4/kernel/sched.c      Wed Apr 11 06:18:46 2001
> @@ -686,8 +686,26 @@
>                 struct task_struct *p;
>                 spin_unlock_irq(&runqueue_lock);
>                 read_lock(&tasklist_lock);
> -               for_each_task(p)
> +               for_each_task(p) {
> +                   if (p->nice <= 0) {
> +                       /* The normal case... */
>                         p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice);
> +                   } else {
> +                       /*
> +                        * Niced tasks get less CPU less often, leading to
> +                        * the following distribution of CPU time:
> +                        *
> +                        * Nice    0    5   10   15   19
> +                        * %CPU  100   56   25    6    1
> +                        */
> +                       short prio = 20 - p->nice;
> +                       p->nice_calc += prio;
> +                       if (p->nice_calc >= 20) {
> +                           p->nice_calc -= 20;
> +                           p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice);
> +                       }
> +                   }
> +               }
>                 read_unlock(&tasklist_lock);
>                 spin_lock_irq(&runqueue_lock);
>         }
> --- linux-2.4.3-ac4/include/linux/sched.h.orig  Tue Apr 10 21:04:13 2001
> +++ linux-2.4.3-ac4/include/linux/sched.h       Wed Apr 11 06:26:47 2001
> @@ -303,7 +303,8 @@
>   * the goodness() loop in schedule().
>   */
>         long counter;
> -       long nice;
> +       short nice_calc;
> +       short nice;
>         unsigned long policy;
>         struct mm_struct *mm;
>         int has_cpu, processor;

Re: [test-PATCH] Re: [QUESTION] 2.4.x nice level

[Pavel Machek]

Hi!

> One rule of optimization is to move any code you can outside the loop. 
> Why isn't the nice_to_ticks calculation done when nice is changed
> instead of EVERY recalc.?  I guess another way to ask this is, who needs

This way change is localized very nicely, and it is "obviously right".

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [test-PATCH] Re: [QUESTION] 2.4.x nice level

[Rik van Riel]

On Thu, 12 Apr 2001, Pavel Machek wrote:

> > One rule of optimization is to move any code you can outside the loop. 
> > Why isn't the nice_to_ticks calculation done when nice is changed
> > instead of EVERY recalc.?  I guess another way to ask this is, who needs
> 
> This way change is localized very nicely, and it is "obviously right".

Except for two obvious things:

1. we need to load the nice level anyway
2. a shift takes less cycles than a load on most
   CPUs

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

Re: [test-PATCH] Re: [QUESTION] 2.4.x nice level

[george anzinger]

Rik van Riel wrote:
> 
> On Thu, 12 Apr 2001, Pavel Machek wrote:
> 
> > > One rule of optimization is to move any code you can outside the loop.
> > > Why isn't the nice_to_ticks calculation done when nice is changed
> > > instead of EVERY recalc.?  I guess another way to ask this is, who needs
> >
> > This way change is localized very nicely, and it is "obviously right".
> 
> Except for two obvious things:
> 
> 1. we need to load the nice level anyway
> 2. a shift takes less cycles than a load on most
>    CPUs
> 
Gosh, what am I missing here?  I think "top" and "ps" want to see the
"nice" value so it needs to be available and since the NICE_TO_TICK()
function looses information (i.e. is not reversible) we can not compute
it from ticks.  Still, yes we need to load something, but is it nice? 
Why not the result of the NICE_TO_TICK()?  

A shift and a subtract are fast, yes, but this loop runs over all tasks
(not just the run list).  This loop can put a real dent in preemption
times AND the notion of turning on interrupts while it is done can run
into some interesting race conditions.  (This is why the MontaVista
scheduler does the loop without dropping the lock, AFTER optimizing the
h... out of it.)

What am I missing?

George