slowdown with new scheduler.

slowdown with new scheduler.

[Dave Jones]

Hi Ingo,
 After adding H7 to 2.4.18pre3, I noticed that kernel compiles
on one of my test boxes got much slower.
Uniprocessor system (Cyrix 3) building a 2.4.18pre3 tree,
with the same .config, and a distclean before starting the compile.

2.4.18pre3        13.38s                       
2.4.18pre+H7      17.53s

I see similar slowdown when running H7 on 2.5 on this box.

regards,
Dave.

-- 
Dave Jones.                    http://www.codemonkey.org.uk
SuSE Labs.

Re: slowdown with new scheduler.

[Antony Suter]

On Mon, 2002-01-14 at 23:45, Dave Jones wrote:
> Hi Ingo,
>  After adding H7 to 2.4.18pre3, I noticed that kernel compiles
> on one of my test boxes got much slower.
> Uniprocessor system (Cyrix 3) building a 2.4.18pre3 tree,
> with the same .config, and a distclean before starting the compile.
> 
> 2.4.18pre3        13.38s                       
> 2.4.18pre+H7      17.53s
> 
> I see similar slowdown when running H7 on 2.5 on this box.

Another anecdote: my dnetc client (niced at 19) scores went from 4.2
Mkeys/s to 4.0 Mkeys/s. (Athlon 1.2GHz tbird).

-- 
- Antony Suter  (antonysuter@optusnet.com.au)  "Examiner" 
openpgp:7916EE67
- "Savahnah River. K Reactor. 1968. It was a very good year."

Re: slowdown with new scheduler.

[Heinz Diehl]

On Mon Jan 14 2002, Dave Jones wrote:

>  After adding H7 to 2.4.18pre3, I noticed that kernel compiles
> on one of my test boxes got much slower.
> Uniprocessor system (Cyrix 3) building a 2.4.18pre3 tree,
> with the same .config, and a distclean before starting the compile.
> 
> 2.4.18pre3        13.38s                       
> 2.4.18pre+H7      17.53s

I did the same; same config, fresh tree, reboot between the test. 
The machine is a (single-processor) AMD K6-2/400 with 256 MB RAM.
Here are the results:

2.4.18-pre3	 	    real    7m55.243s
			    user    6m34.080s
			    sys     0m27.610s

2.4.18-pre+H7		    real    7m35.962s
			    user    6m34.270s
			    sys     0m27.700s

2.4.18-pre3-ac2		    real    7m39.203s
			    user    6m34.110s
			    sys     0m28.740s

Ingo's scheduler rocks, it runs like hell (and is absolutely stable here)  ;)

-- 
# Heinz Diehl, 68259 Mannheim, Germany

Re: slowdown with new scheduler.

[Dave Jones]

On Mon, Jan 14, 2002 at 06:20:10PM +0100, Heinz Diehl wrote:
 > I did the same; same config, fresh tree, reboot between the test. 
 > The machine is a (single-processor) AMD K6-2/400 with 256 MB RAM.
 > Here are the results:
 > ... <deletia>
 > Ingo's scheduler rocks, it runs like hell (and is absolutely stable here)  ;)

 The issue seems to be when a process like dnetc is running
 (which runs at +19 iirc), it seems to be getting scheduled way too
 often.
 
-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: slowdown with new scheduler.

[Heinz Diehl]

On Mon Jan 14 2002, Heinz Diehl wrote:

> 2.4.18-pre3	 	    real    7m55.243s
> 			    user    6m34.080s
> 			    sys     0m27.610s
> 
> 2.4.18-pre+H7		    real    7m35.962s
> 			    user    6m34.270s
> 			    sys     0m27.700s
> 
> 2.4.18-pre3-ac2	    real    7m39.203s
> 			    user    6m34.110s
> 			    sys     0m28.740s
> 

2.4.18-pre3+H7+preempt-rml  real    6m58.983s
 			    user    6m34.500s
 			    sys     0m27.820s

:))

-- 
# Heinz Diehl, 68259 Mannheim, Germany

Re: slowdown with new scheduler.

[Banai Zoltan]

On Mon, Jan 14, 2002 at 08:29:25PM +0100, Heinz Diehl wrote:
> On Mon Jan 14 2002, Heinz Diehl wrote:
> 
> > 2.4.18-pre3	 	    real    7m55.243s
> > 			    user    6m34.080s
> > 			    sys     0m27.610s
> > 
> > 2.4.18-pre+H7		    real    7m35.962s
> > 			    user    6m34.270s
> > 			    sys     0m27.700s
> > 
> > 2.4.18-pre3-ac2	    real    7m39.203s
> > 			    user    6m34.110s
> > 			    sys     0m28.740s
> > 
> 
> 2.4.18-pre3+H7+preempt-rml  real    6m58.983s
>  			    user    6m34.500s
>  			    sys     0m27.820s
> 
That sounds very good! But what about the VM code?
Is the VM in 2.4.18-pre3+H7 as good as in 2.4.18-pre2aa2?

Re: slowdown with new scheduler.

[Dieter Nützel]

On Monday, 14. January 2002 20:42, you wrote:
> On Mon, Jan 14, 2002 at 08:29:25PM +0100, Heinz Diehl wrote:
> > On Mon Jan 14 2002, Heinz Diehl wrote:
> >
> > > 2.4.18-pre3             real    7m55.243s
> > >                         user    6m34.080s
> > >                         sys     0m27.610s
> > > 
> > > 2.4.18-pre+H7                   real    7m35.962s
> > >                         user    6m34.270s
> > >                         sys     0m27.700s
> > > 
> > > 2.4.18-pre3-ac2         real    7m39.203s
> > >                         user    6m34.110s
> > >                         sys     0m28.740s
> > > 
> >
> > 2.4.18-pre3+H7+preempt-rml  real    6m58.983s
> >                           user    6m34.500s
> >                           sys     0m27.820s
> >
> That sounds very good! But what about the VM code?
> Is the VM in 2.4.18-pre3+H7 as good as in 2.4.18-pre2aa2?

Of course _NOT_.
This is like apples and oranges...

You _must_ compare
2.4.18-pre3+H7+ -aa vm-22 from 2.4.18-pre2aa2
with
2.4.18-pre3+H7+ -rmap

After that you should apply preempt+locl-break or LL to both.

Have a look into Re: [2.4.17/18pre] VM and swap - it's really unusable

Greetings,
	Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel@hamburg.de

Re: slowdown with new scheduler.

[Heinz Diehl]

On Mon Jan 14 2002, Dieter Nützel wrote:

> You _must_ compare
> 2.4.18-pre3+H7+ -aa vm-22 from 2.4.18-pre2aa2
> with
> 2.4.18-pre3+H7+ -rmap

This is not possible for me since rmap-11b does not apply cleanly to
2.4.18-pre3+H7, several hunks fail. I'm not a programmer, so I'm 
not able to make the patches fit together.

> After that you should apply preempt+locl-break or LL to both.

The same here, lock-break does not apply to 2.4.18-pre3+H7 without 
some failed hunks....

-- 
# Heinz Diehl, 68259 Mannheim, Germany

Re: slowdown with new scheduler.

[Robert Love]

On Mon, 2002-01-14 at 17:40, Heinz Diehl wrote:

> > After that you should apply preempt+locl-break or LL to both.
> 
> The same here, lock-break does not apply to 2.4.18-pre3+H7 without 
> some failed hunks....

Just a note, if lock-break fails in chunks it is probably OK to just
ignore them.  Each lock-break is independent so, while it is less lock
breaking, it is nearly the same and certainly works fine.

Wouldn't give the same advice for rmap, however.  Best to make sure your
VM applies cleanly :)

	Robert Love