Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Sep 2005 01:04:40 +0200
From:      Emanuel Strobl <Emanuel.strobl@gmx.net>
To:        freebsd-current@freebsd.org
Cc:        David Xu <davidxu@freebsd.org>, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: 4BSD/ULE numbers...
Message-ID:  <200509270104.48754@harrymail>
In-Reply-To: <43387811.1090308@freebsd.org>
References:  <200509261847.35558@harrymail> <20050926174738.GA57284@xor.obsecurity.org> <43387811.1090308@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2298045.IkdbGiNYLN
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Dienstag, 27. September 2005 00:37 CEST schrieb David Xu:
[...]
> I am fiddling it, although I don't know when I can finish.
> In fact, the ULE code in my perforce has same performance as
> 4BSD, at least this is true on my Dual PIII machine. the real
> advantage is ULE can be HTT friendly if it make it correctly,
> for example physical / logical CPU balance, if system has two
> HTT enabled physical CPU, if system has too CPU hog threads,
> you definitely want the two threads to run on the two physical
> cpu, not in same phyiscal cpu.

I'm sure ULE is on it's way to be our prefered scheduler, especially on MP=
=20
machines, where it's probably already superior, and I don't really care=20
much about the small differences in bonnie++ or flops bench-results, nor=20
in the small timing differences, but I'm astonished about the really big=20
gap between the "make configure" timings of ULE and 4BSD. (on my Tualatin=20
UP)
The difference is really enormuous (samba.configure.bsd.time compared to=20
samba.configure.ule.time =3D=3D 3m15s <-> 5m30s) and there's still a thing =
I=20
observed some years ago (about two, when I ran seti@home in the=20
background): ULE isn't "nice" friendly, meaning other applications suffer=20
from niced processes much more than under 4BSD. Ideally, in my dreams, no=20
other process would loose performance because of any "niced" process.=20
Watch the samba.configure.ule.nonice.time -> samba.configure.ule.time=20
results, they're nearly identical...

But that's the point where I have to leave this discussion, my knowledge is=
=20
very limited in that area, so I just wanted to give info/hints to help the=
=20
gurus improoving the best. The better is the bests enemy... ;)
And I hope I can help with "real world" tests to see ULE outperforming 4BSD=
=20
even on UP machines with bonnie++ (where I see the second significant=20
difference)

Best regards!

=2DHarry

> but current it is not. Another advantage is when sched_lock pushes
> down, I know current sched_lock is a Giant lock between large
> number of CPU, also I don't know when sched_lock will be pushed
> down, sched_lock is abused in many place, they really can be replaced
> by another spin lock. :)
>
> David Xu

--nextPart2298045.IkdbGiNYLN
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)

iD8DBQBDOH6QBylq0S4AzzwRAj11AJ0Y4FxWzDUp2VUiQ3sf1KPhcG6T1gCfTYAL
hWSgqmfGuJPptpqK+BYUPeM=
=FIYL
-----END PGP SIGNATURE-----

--nextPart2298045.IkdbGiNYLN--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509270104.48754>