Re: [PATCH] Balanced Multi Queue Scheduler ...

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Dieter Nützel]

Davide worte:
> There's a bug fix and the use of the Time Slice Split Scheduler inside the
> local CPUs schedulers. Versions from 0.46 to 0.52 are broken by the fixed
> bug so testers should use this version :
>
> http://www.xmailserver.org/linux-patches/mss-2.html#patches

Sorry, if someone asks this before but do you think that you get some stuff 
out of it for 2.4.xx?

Your numbers for the 8 SMP system are great.
Can't wait to do some tests on my poor single 1 GHz Athlon II and soon dual 
Athlon MP/XP 1600+ on an MS 6501 (AMD 760MPX).

Maybe my MP3/Ogg-Vorbis hiccup during dbench 32+ are solved?
Currently running latest 2.4.17+preempt (do think that can be mixed with your 
new scheduler?).

Thanks,
	Dieter

-- 
Dieter Nützel
Graduate Student, Computer Science

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

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Davide Libenzi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1207 bytes --]

On Sat, 29 Dec 2001, Dieter [iso-8859-15] Nützel wrote:

> Davide worte:
> > There's a bug fix and the use of the Time Slice Split Scheduler inside the
> > local CPUs schedulers. Versions from 0.46 to 0.52 are broken by the fixed
> > bug so testers should use this version :
> >
> > http://www.xmailserver.org/linux-patches/mss-2.html#patches
>
> Sorry, if someone asks this before but do you think that you get some stuff
> out of it for 2.4.xx?
>
> Your numbers for the 8 SMP system are great.
> Can't wait to do some tests on my poor single 1 GHz Athlon II and soon dual
> Athlon MP/XP 1600+ on an MS 6501 (AMD 760MPX).
>
> Maybe my MP3/Ogg-Vorbis hiccup during dbench 32+ are solved?
> Currently running latest 2.4.17+preempt (do think that can be mixed with your
> new scheduler?).

The new patch need ver >= 2.5.2-pre3 because Linus merged the Time Slice
Split Scheduler and making it to apply to 2.4.x could be a pain in the b*tt.
Yes, as i expected numbers on big SMP are very good but still i don't
think that this can help you with your problem.
It'd be nice to have inside local_irq_disable()/enable() a cycle counter
sampler to see what is the worst case path with disabled irqs.




- Davide

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Andrew Morton]

Davide Libenzi wrote:
> 
> On Sat, 29 Dec 2001, Dieter [iso-8859-15] Nützel wrote:
> 
> > Davide worte:
> > > There's a bug fix and the use of the Time Slice Split Scheduler inside the
> > > local CPUs schedulers. Versions from 0.46 to 0.52 are broken by the fixed
> > > bug so testers should use this version :
> > >
> > > http://www.xmailserver.org/linux-patches/mss-2.html#patches
> >
> > Sorry, if someone asks this before but do you think that you get some stuff
> > out of it for 2.4.xx?
> >
> > Your numbers for the 8 SMP system are great.
> > Can't wait to do some tests on my poor single 1 GHz Athlon II and soon dual
> > Athlon MP/XP 1600+ on an MS 6501 (AMD 760MPX).
> >
> > Maybe my MP3/Ogg-Vorbis hiccup during dbench 32+ are solved?
> > Currently running latest 2.4.17+preempt (do think that can be mixed with your
> > new scheduler?).
> 
> The new patch need ver >= 2.5.2-pre3 because Linus merged the Time Slice
> Split Scheduler and making it to apply to 2.4.x could be a pain in the b*tt.
> Yes, as i expected numbers on big SMP are very good but still i don't
> think that this can help you with your problem.

I would expect the audio dropouts to be due to disk read latencies
and insufficiently large buffers in the audio app, and/or failure
of that audio app to mlock itself down.

If it's scheduling latency, which I doubt, I yesterday put out
a 2.4.17 low-latency patch which has a worst-case latency which is
two orders of magnitude less that the preemptive kernel's.  The
lock-break patch will improve the preempt patch's worst case.
http://www.zip.com.au/~akpm/linux/2.4.17-low-latency.patch.gz

> It'd be nice to have inside local_irq_disable()/enable() a cycle counter
> sampler to see what is the worst case path with disabled irqs.
> 

http://www.zip.com.au/~akpm/linux/#intlat

This tool needs a bit of maintenance work, but it can measure and identify
the source of worst-case interrupt latencies quite successfully.

-

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Stephan von Krawczynski]

> On Sat, 29 Dec 2001, Dieter [iso-8859-15] Nützel wrote:             
>                                                                     
> The new patch need ver >= 2.5.2-pre3 because Linus merged the Time  
Slice                                                                 
> Split Scheduler and making it to apply to 2.4.x could be a pain in  
the b*tt.                                                             
> Yes, as i expected numbers on big SMP are very good but still i     
don't                                                                 
> think that this can help you with your problem.                     
                                                                      
Just a short note on that:                                            
                                                                      
Before the scheduler stuff really got rolling there was a pretty      
distinct discussion why L didn't quite get involved in the thread. I  
may remind you that he thought it to be not a _that_ interesting stuff
and I well remember he said something about the smallness and the low 
possibility that it gets broken by (well-thought-out) patches. This   
leads me to believe he has no major issues with enhancements to 2.4   
scheduler.                                                            
Well, me neither :-)                                                  
In fact we should keep in mind that 2.5 is a _development_ kernel and 
a next stable branch is out-of-sight at this time. So it would be     
quite reasonable to do a "backport" to 2.4 of the scheduler, because  
SMP systems do get more in size and number today and the near future. 
And we should not expect the not-LKML world to use _development_      
kernels on their cool-nu-SMP-box (tm), because this can only be bad   
for ongoing comparisons with other OSs. Well, you know what I mean.   
In fact I can see two major steps to take for marcelo's maintenance   
(besides the bugfixes of course):                                     
1) the SMP-scheduling (its all yours, Davide :-)                      
2) the HIGHMEM problems (a warm welcome to Andrea :-)                 
We cannot deny the fact that people expect the scalability of the     
system, and just to give you a small hint, I personally already       
stopped buying UP machines. There is no real big difference in prices 
between UP and 2-SMP these days, and RAM is unbelievably cheap in this
decade - and it makes your seti-statistics fly ;-)                    
So these issues will be very much in the mainstream of all users. No  
way to deny this.                                                     
I have no fear: this is a reachable goal, let's just take it.         
                                                                      
Regards,                                                              
Stephan                                                               
                                                                      
PS: Yes, Alan, I read your mail about the 32GB box and DMA and stuff, 
but nevertheless we should keep up with the market-ongoings (damn     
cheap 1GB modules).                                                   
                                                                      
                                                                      

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Davide Libenzi]

On Sat, 29 Dec 2001, Andrew Morton wrote:

> > It'd be nice to have inside local_irq_disable()/enable() a cycle counter
> > sampler to see what is the worst case path with disabled irqs.
> >
>
> http://www.zip.com.au/~akpm/linux/#intlat
>
> This tool needs a bit of maintenance work, but it can measure and identify
> the source of worst-case interrupt latencies quite successfully.

Thx, i'll take a look.



- Davide

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Davide Libenzi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2533 bytes --]

On Sun, 30 Dec 2001, Stephan von Krawczynski wrote:

> > On Sat, 29 Dec 2001, Dieter [iso-8859-15] Nützel wrote:
> >
> > The new patch need ver >= 2.5.2-pre3 because Linus merged the Time
> Slice
> > Split Scheduler and making it to apply to 2.4.x could be a pain in
> the b*tt.
> > Yes, as i expected numbers on big SMP are very good but still i
> don't
> > think that this can help you with your problem.
>
> Just a short note on that:
>
> Before the scheduler stuff really got rolling there was a pretty
> distinct discussion why L didn't quite get involved in the thread. I
> may remind you that he thought it to be not a _that_ interesting stuff
> and I well remember he said something about the smallness and the low
> possibility that it gets broken by (well-thought-out) patches. This
> leads me to believe he has no major issues with enhancements to 2.4
> scheduler.
> Well, me neither :-)
> In fact we should keep in mind that 2.5 is a _development_ kernel and
> a next stable branch is out-of-sight at this time. So it would be
> quite reasonable to do a "backport" to 2.4 of the scheduler, because
> SMP systems do get more in size and number today and the near future.
> And we should not expect the not-LKML world to use _development_
> kernels on their cool-nu-SMP-box (tm), because this can only be bad
> for ongoing comparisons with other OSs. Well, you know what I mean.

I think Alan is interested doing a back port + testing on 2.4.x
Even if i kindly agree with Linus that the scheduler code cannot screw up
that much you've to remember that this is brand new code and it needs
testing and polishing. And maybe trashing :)


> In fact I can see two major steps to take for marcelo's maintenance
> (besides the bugfixes of course):
> 1) the SMP-scheduling (its all yours, Davide :-)
> 2) the HIGHMEM problems (a warm welcome to Andrea :-)

Yep, next on your screens, "GodFather IV" :)


> We cannot deny the fact that people expect the scalability of the
> system, and just to give you a small hint, I personally already
> stopped buying UP machines. There is no real big difference in prices
> between UP and 2-SMP these days, and RAM is unbelievably cheap in this
> decade - and it makes your seti-statistics fly ;-)
> So these issues will be very much in the mainstream of all users. No
> way to deny this.
> I have no fear: this is a reachable goal, let's just take it.

You can still live with the current scheduler on 2SMP while what i'm
seeing on an 8SMP is a completely different picture.




- Davide

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Alan Cox]

> PS: Yes, Alan, I read your mail about the 32GB box and DMA and stuff,=20
> but nevertheless we should keep up with the market-ongoings (damn    =20
> cheap 1GB modules).                                                  =20

Hopefully that will be followed be sanely priced Hammer processors before
we end up with 4Gb EMS boards and extended memory and other horrors 8)

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Dieter Nützel]

On Sunday, 30. December 2001 03:32, Alan Cox wrote:
> > PS: Yes, Alan, I read your mail about the 32GB box and DMA and stuff,=20
> > but nevertheless we should keep up with the market-ongoings (damn    =20
> > cheap 1GB modules).                                                  =20
>
> Hopefully that will be followed be sanely priced Hammer processors before
> we end up with 4Gb EMS boards and extended memory and other horrors 8)

You mean the AMD "Hammer family"? :-)))

Happy New Year!
		Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

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

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Timothy Covell]

On Saturday 29 December 2001 17:38, Stephan von Krawczynski wrote:
[snip]
> We cannot deny the fact that people expect the scalability of the
> system, and just to give you a small hint, I personally already
> stopped buying UP machines. There is no real big difference in prices
> between UP and 2-SMP these days, and RAM is unbelievably cheap in this
> decade - and it makes your seti-statistics fly ;-)

Ummm, on my Dual P-III (650MHz with 524988416 Bytes), my current Seti 
efficiency is 5.35 CpF.   That's a tad high/slower than an Ultra Sparc IIi 
according to their stats.  So, it would appear that being SMP is hurting my 
performance a bit.   Unless that is that you meant to run a seti instance for 
each CPU?   And this reminds me of how "make -j3 bzlilo" is slower than
"make -j2 bzlilo".

> So these issues will be very much in the mainstream of all users. No
> way to deny this.
> I have no fear: this is a reachable goal, let's just take it.
>
> Regards,
> Stephan
>
> PS: Yes, Alan, I read your mail about the 32GB box and DMA and stuff,
> but nevertheless we should keep up with the market-ongoings (damn
> cheap 1GB modules).
>
>
> -
> 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/

-- 
timothy.covell@ashavan.org.

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Davide Libenzi]

On Sun, 30 Dec 2001, Timothy Covell wrote:

> each CPU?   And this reminds me of how "make -j3 bzlilo" is slower than
> "make -j2 bzlilo".

Running N CPU bound tasks on an M way SMP machine with N > M is never
going to improve your performace. On the contrary, expecially with the
current scheduler that keeps rotating the three tasks between the two
CPUs, you're going to suffer a slight performance degradation.



- Davide

Re: [PATCH] Balanced Multi Queue Scheduler ...

[J Sloan]

Timothy Covell wrote:

>Ummm, on my Dual P-III (650MHz with 524988416 Bytes), my current Seti 
>efficiency is 5.35 CpF.   That's a tad high/slower than an Ultra Sparc IIi 
>according to their stats.  So, it would appear that being SMP is hurting my 
>performance a bit.   Unless that is that you meant to run a seti instance for 
>each CPU?   And this reminds me of how "make -j3 bzlilo" is slower than
>"make -j2 bzlilo".
>
Eh?

On my 4-way ppro, make -j4 is much faster
than a simple "make" for kernel compilation.
Almost linearly so -

This is with recent 2.4.1x kernels BTW on
Red Hat 7.1/7.2

Sorry to hear of your bizzare experiences -
but then again, maybe you're running a
2.2.x kernel or something?

cu

jjs

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Davide Libenzi]

On Sun, 30 Dec 2001, J Sloan wrote:

> Timothy Covell wrote:
>
> >Ummm, on my Dual P-III (650MHz with 524988416 Bytes), my current Seti
> >efficiency is 5.35 CpF.   That's a tad high/slower than an Ultra Sparc IIi
> >according to their stats.  So, it would appear that being SMP is hurting my
> >performance a bit.   Unless that is that you meant to run a seti instance for
> >each CPU?   And this reminds me of how "make -j3 bzlilo" is slower than
> >"make -j2 bzlilo".
> >
> Eh?
>
> On my 4-way ppro, make -j4 is much faster
> than a simple "make" for kernel compilation.
> Almost linearly so -

He's saying -j3 on a dual CPU



- Davide

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Alan Cox]

> On my 4-way ppro, make -j4 is much faster
> than a simple "make" for kernel compilation.
> Almost linearly so -

Make does lots of I/O and also has lots of stuff that can run in parallel
and balance out easily. The real test case for you to try are 5, 6, 7, and 8
copies of seti

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Stephan von Krawczynski]

> On Saturday 29 December 2001 17:38, Stephan von Krawczynski wrote:  
> [Offtopic seti hints :-) ]                                          
> Ummm, on my Dual P-III (650MHz with 524988416 Bytes), my current    
Seti                                                                  
> efficiency is 5.35 CpF.   That's a tad high/slower than an Ultra    
Sparc IIi                                                             
> according to their stats.  So, it would appear that being SMP is    
hurting my                                                            
> performance a bit.   Unless that is that you meant to run a seti    
instance for                                                          
> each CPU?                                                           
                                                                      
Yes, exactly, use one seti per cpu and you will be happy :-)          
As far as I know they intended it this way.                           
                                                                      
Regards,                                                              
Stephan                                                               
                                                                      

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Stephan von Krawczynski]

> On Sun, 30 Dec 2001, Timothy Covell wrote:                          
>                                                                     
> > each CPU?   And this reminds me of how "make -j3 bzlilo" is slower
than                                                                  
> > "make -j2 bzlilo".                                                
>                                                                     
> Running N CPU bound tasks on an M way SMP machine with N > M is     
never                                                                 
> going to improve your performace. On the contrary, expecially with  
the                                                                   
> current scheduler that keeps rotating the three tasks between the   
two                                                                   
> CPUs, you're going to suffer a slight performance degradation.      
                                                                      
And can you please post a patch for this?                             
                                                                      
;-)                                                                   
                                                                      
Honestly: it _should_ be fixed, there is a better way of doing it, and
this is the base for a patch.                                         
                                                                      
Regards,                                                              
Stephan                                                               
                                                                      
                                                                      
                                                                      

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Davide Libenzi]

On Mon, 31 Dec 2001, Stephan von Krawczynski wrote:

> > On Sun, 30 Dec 2001, Timothy Covell wrote:
> >
> > > each CPU?   And this reminds me of how "make -j3 bzlilo" is slower
> than
> > > "make -j2 bzlilo".
> >
> > Running N CPU bound tasks on an M way SMP machine with N > M is
> never
> > going to improve your performace. On the contrary, expecially with
> the
> > current scheduler that keeps rotating the three tasks between the
> two
> > CPUs, you're going to suffer a slight performance degradation.
>
> And can you please post a patch for this?

http://www.xmailserver.org/linux-patches/mss-2.html#patches



- Davide

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Stephan von Krawczynski]

On Sun, 30 Dec 2001 15:46:13 -0800 (PST)
Davide Libenzi <davidel@xmailserver.org> wrote:

> > And can you please post a patch for this?
> 
> http://www.xmailserver.org/linux-patches/mss-2.html#patches

Sorry, I meant for 2.4 :-)

Regards,
Stephan

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Davide Libenzi]

On Mon, 31 Dec 2001, Stephan von Krawczynski wrote:

> On Sun, 30 Dec 2001 15:46:13 -0800 (PST)
> Davide Libenzi <davidel@xmailserver.org> wrote:
>
> > > And can you please post a patch for this?
> >
> > http://www.xmailserver.org/linux-patches/mss-2.html#patches
>
> Sorry, I meant for 2.4 :-)

I continue the development on 2.5.x sorry. Some good news could come from
Alan anyway.



- Davide

Re: [PATCH] Balanced Multi Queue Scheduler ...

[Bill Davidsen]

On Sun, 30 Dec 2001, Timothy Covell wrote:

> Ummm, on my Dual P-III (650MHz with 524988416 Bytes), my current Seti 
> efficiency is 5.35 CpF.   That's a tad high/slower than an Ultra Sparc IIi 
> according to their stats.  So, it would appear that being SMP is hurting my 
> performance a bit.   Unless that is that you meant to run a seti instance for 
> each CPU?   And this reminds me of how "make -j3 bzlilo" is slower than
> "make -j2 bzlilo".

make -j3 bzlilo
make bzlilo MAKE='make -j3'

See if it runs differently on your machine, mem size may matter.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

[PATCH] Balanced Multi Queue Scheduler ...

[Davide Libenzi]

There's a bug fix and the use of the Time Slice Split Scheduler inside the
local CPUs schedulers. Versions from 0.46 to 0.52 are broken by the fixed
bug so testers should use this version :

http://www.xmailserver.org/linux-patches/mss-2.html#patches




- Davide