[QUESTION] 2.4.x nice level

[QUESTION] 2.4.x nice level

[BERECZ Szabolcs]

Hi!

I just noticed, that a process with nice level 19, gets some processor
time, even if there is another process, which would use all of the
processor time.
for example, there is a setiathome running at nice level 19, and a
bladeenc at nice level 0. setiathome uses 14 percent, and bladeenc uses 84
percent of the processor. I think, setiathome should use max 2-3 percent.
the 14 percent is way too much for me.
or is there any other way to run a process only if nothing uses the
processor?
with kernel 2.2.16 it worked for me.
now I use 2.4.2-ac20

Bye,
Szabi

Re: [QUESTION] 2.4.x nice level

[Quim K Holland]

>>>>> "BS" == BERECZ Szabolcs <szabi@inf.elte.hu> writes:

BS> ... a setiathome running at nice level 19, and a bladeenc at
BS> nice level 0. setiathome uses 14 percent, and bladeenc uses
BS> 84 percent of the processor. I think, setiathome should use
BS> max 2-3 percent.  the 14 percent is way too much for me.
BS> ...
BS> with kernel 2.2.16 it worked for me.
BS> now I use 2.4.2-ac20

Would it the case that bladeenc running on 2.4.2 spends more
time doing I/O?  I am not saying that the userland makes more I/O
requests, but if the same set of I/O requests are taking longer
to complete on 2.4.2, then while bladeenc is waiting for their
completion, it is not so surprising that the other process uses
the otherwise-idle CPU cycles.



------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/

Re: [QUESTION] 2.4.x nice level

[LA Walsh]

Quim K Holland wrote:
> 
> >>>>> "BS" == BERECZ Szabolcs <szabi@inf.elte.hu> writes:
> 
> BS> ... a setiathome running at nice level 19, and a bladeenc at
> BS> nice level 0. setiathome uses 14 percent, and bladeenc uses
> BS> 84 percent of the processor. I think, setiathome should use
> BS> max 2-3 percent.  the 14 percent is way too much for me.
> BS> ...
> BS> with kernel 2.2.16 it worked for me.
> BS> now I use 2.4.2-ac20
---
	I was running 2 copies of setiathome on a 4 CPU server
@ work.  The two processes ran nice'd -19.  The builds we were 
running still took 20-30% longer as opposed to when setiathome wasn't
running (went from 45 minutes up to about an hour).  This machine
has 1G, so I don't think it was hurting from swapping.

I finally wrote a script that checked every 30 seconds -- if the
load on the machine climbed over '4', the script would SIGSTOP the
seti jobs.  Once the load on the machine fell below 2, it would 
send a SIGCONT to them.  

I was also running setiathome on my laptop for a short while --
but the fan kept coming on and the computer would get really hot.
So I stopped that.  Linux @ idle doesn't seem to ever kick on
the fan, but turn on a CPU cruching program and it sure seemed
to heat up the machine.  I still wonder how many kilo or mega watts
go to running dispersed computation programs.  Just one of those
things I may never know....

-l

-- 
The above thoughts and           | They may have nothing to do with
writings are my own.             | the opinions of my employer. :-)
L A Walsh                        | Trust Technology, Core Linux, SGI
law@sgi.com                      | Voice: (650) 933-5338

[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

[Tor Arntsen]

LA Walsh <law@sgi.com> writes:
>	I was running 2 copies of setiathome on a 4 CPU server
>@ work.  The two processes ran nice'd -19.  The builds we were 
>running still took 20-30% longer as opposed to when setiathome wasn't
>running (went from 45 minutes up to about an hour).  This machine
>has 1G, so I don't think it was hurting from swapping.

It would be nice to have IRIX weightless processes on Linux.. 
setiathome on SGI computers don't affect anything else except
in extreme cases.

-Tor

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