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
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: [email protected]
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
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.
-
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
> 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).
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
> 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)
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: [email protected]
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
[email protected].
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
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
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
> 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
> 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
> 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
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
On Sun, 30 Dec 2001 15:46:13 -0800 (PST)
Davide Libenzi <[email protected]> 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
On Mon, 31 Dec 2001, Stephan von Krawczynski wrote:
> On Sun, 30 Dec 2001 15:46:13 -0800 (PST)
> Davide Libenzi <[email protected]> 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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.