Re: 4BSD/ULE numbers...

From: Kris Kennaway (kris_at_obsecurity.org)
Date: 09/27/05

  • Next message: Emanuel Strobl: "Re: 4BSD/ULE numbers..."
    Date: Mon, 26 Sep 2005 18:44:53 -0400
    To: David Xu <davidxu@freebsd.org>
    
    
    

    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

    
    



  • Next message: Emanuel Strobl: "Re: 4BSD/ULE numbers..."

    Relevant Pages

    • Re: 4BSD/ULE numbers...
      ... September 2005 00:37 CEST schrieb David Xu: ... > advantage is ULE can be HTT friendly if it make it correctly, ... > for example physical / logical CPU balance, ... machines, where it's probably already superior, and I don't really care ...
      (freebsd-current)
    • Re: ULE 2.0
      ... After a considerable vacation from ULE I have come back to address some long standing concerns. ... See %cpu in top. ... and destroy a partition, root can add cpu to the partition or remove ... I feel that working within the framework of the 4BSD scheduler would limit what we can do with these more complex scheduling problems. ...
      (freebsd-current)
    • Re: HEADS UP: ULE is the default scheduler now
      ... Jeff, were you able to clear up the use of ULE on a single CPU machine ... >> ULE has entered into its probationary period as the default scheduler. ... interactivity is reported to be better in many ...
      (freebsd-current)
    • Re: On schedulers
      ... I wasn't really interested in 3D performance, but mostly in if there's theoretical modelling of how ULE should perform, and/or its comparison to Linux. ... That is it attempts to give all processes an equal fraction of the CPU within a given period. ... An interactive task which uses too much CPU will be bounced back to split time evenly. ... In this case you can tune down the interactivity threshold, or it could be disabled all together, giving results similar to 4BSD/CFS. ...
      (freebsd-arch)
    • Re: 4BSD/ULE numbers...
      ... >>I tried ULE with BETA5 and for me it felt a bit sluggish when making ports. ... HTT enabled physical CPU, if system has too CPU hog threads, ... I know current sched_lock is a Giant lock between large ...
      (freebsd-current)