Hi all, I found that slice_min and slice_max in sched_ule.c are calculated based on hz rather than stathz, which results to a thread hogging 7.5 times more cpu time than the author's intension. For those who feel sluggish when doing computation-bound things, I recommend the following tunings with sysctl: # for RTC based systems... kern.sched.slice_min=1 kern.sched.slice_max=18 # for APIC based systems driven at hz=1000 # (where stathz = hz * 2 / 15) kern.sched.slice_min=1 # (hz * 2 / 15) / 100 kern.sched.slice_max=19 # (hz * 2 / 15) / 7 The attached patch addresses this problem with the bonus of increased accuracy of tickincr. On Mon, 26 Sep 2005 13:47:38 -0400 Kris Kennaway <kris_at_obsecurity.org> 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 -- -|-__ YAMAMOTO, Taku | __ < <taku_at_tackymt.homeip.net>
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:44 UTC