Re: 4BSD/ULE numbers...

From: David Xu (davidxu_at_freebsd.org)
Date: 09/27/05

  • Next message: Kris Kennaway: "Re: [PANIC] ufs_dirbad: bad dir" 
    Date: Tue, 27 Sep 2005 06:37:05 +0800
To: Kris Kennaway <kris@obsecurity.org>

    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. :)

    David Xu

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Kris Kennaway: "Re: [PANIC] ufs_dirbad: bad dir"

    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...
      ... > Kris Kennaway wrote: ... the ULE code in my perforce has same performance as ... > for example physical / logical CPU balance, ... I know current sched_lock is a Giant lock between large ...
      (freebsd-current)