On Tue, Sep 27, 2005 at 06:37:05AM +0800, David Xu wrote: > Kris Kennaway wrote: > > >On Mon, Sep 26, 2005 at 06:47:27PM +0200, Emanuel Strobl wrote: > > > > > >>Hello, > >> > >>I tried ULE with BETA5 and for me it felt a bit sluggish when making > >>ports. > >>So I did some "realworld" simulation and compared 4BSD/ULE to see what > >>numbers tell me. And the prooved my feeling right. > >>It seems that ULE is priorizing nice a little higher, but in general the > >>output of the 4 BSD machine is higher and finishing the tests took not so > >>long as with ULE, especially the "make configure" differs horribly. > >> > >> > > > >That's consistent with my testing. ULE seems a bit more stable now in > >6.0 (except on my large SMP machines, which reboot spontaneously under > >moderate load), but it doesn't perform as well as 4BSD under real > >application workloads. > > > >Kris > > > 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. > 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. :) I'd love a way to measure sched_lock contention..I'm sure it's a factor on e.g. my machines with >=10 CPUs, but mutex profiling doesn't see it because it's a spinlock. Kris
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:44 UTC