From owner-freebsd-current@FreeBSD.ORG Thu Sep 29 23:33:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 266A016A420 for ; Thu, 29 Sep 2005 23:33:17 +0000 (GMT) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (YahooBB219182046034.bbtec.net [219.182.46.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65A7343D49 for ; Thu, 29 Sep 2005 23:33:15 +0000 (GMT) (envelope-from taku@tackymt.homeip.net) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 8B7731074B for ; Fri, 30 Sep 2005 08:33:14 +0900 (JST) Received: from basalt.tackymt.homeip.net ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92588-09 for ; Fri, 30 Sep 2005 08:33:13 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTP for ; Fri, 30 Sep 2005 08:33:13 +0900 (JST) Date: Fri, 30 Sep 2005 08:33:13 +0900 From: Taku YAMAMOTO To: freebsd-current@freebsd.org Message-Id: <20050930083313.72f9801a.taku@tackymt.homeip.net> In-Reply-To: <20050926174738.GA57284@xor.obsecurity.org> References: <200509261847.35558@harrymail> <20050926174738.GA57284@xor.obsecurity.org> X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__30_Sep_2005_08_33_13_+0900_R2RmpAqq+BZmQSkF" X-Virus-Scanned: amavisd-new at tackymt.homeip.net Subject: Re: 4BSD/ULE numbers... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2005 23:33:17 -0000 This is a multi-part message in MIME format. --Multipart=_Fri__30_Sep_2005_08_33_13_+0900_R2RmpAqq+BZmQSkF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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 | __ < --Multipart=_Fri__30_Sep_2005_08_33_13_+0900_R2RmpAqq+BZmQSkF Content-Type: text/plain; name="sched_ule.c-tickmods.diff" Content-Disposition: attachment; filename="sched_ule.c-tickmods.diff" Content-Transfer-Encoding: 7bit --- sched_ule.c.orig Thu Sep 22 10:25:31 2005 +++ sched_ule.c Thu Sep 22 10:25:31 2005 @@ -69,6 +69,9 @@ SYSCTL_INT(_kern, OID_AUTO, ccpu, CTLFLA static void sched_setup(void *dummy); SYSINIT(sched_setup, SI_SUB_RUN_QUEUE, SI_ORDER_FIRST, sched_setup, NULL) +static void sched_initticks(void *dummy); +SYSINIT(sched_initticks, SI_SUB_CLOCKS, SI_ORDER_THIRD, sched_initticks, NULL) + static SYSCTL_NODE(_kern, OID_AUTO, sched, CTLFLAG_RW, 0, "Scheduler"); SYSCTL_STRING(_kern_sched, OID_AUTO, name, CTLFLAG_RD, "ule", 0, @@ -81,7 +84,7 @@ static int slice_max = 10; SYSCTL_INT(_kern_sched, OID_AUTO, slice_max, CTLFLAG_RW, &slice_max, 0, ""); int realstathz; -int tickincr = 1; +int tickincr = 1 << 10; /* * The following datastructures are allocated within their parent structure @@ -921,6 +924,11 @@ sched_setup(void *dummy) int i; #endif + /* + * To avoid divide-by-zero, we set realstathz a dummy value + * in case which sched_clock() called before sched_initticks(). + */ + realstathz = hz; slice_min = (hz/100); /* 10ms */ slice_max = (hz/7); /* ~140ms */ @@ -1011,6 +1019,26 @@ sched_setup(void *dummy) mtx_unlock_spin(&sched_lock); } +/* ARGSUSED */ +static void +sched_initticks(void *dummy) +{ + mtx_lock_spin(&sched_lock); + realstathz = stathz ? stathz : hz; + slice_min = (realstathz/100); /* 10ms */ + slice_max = (realstathz/7); /* ~140ms */ + + tickincr = (hz << 10) / realstathz; + /* + * XXX This does not work for values of stathz that are much + * larger than hz. + */ + if (tickincr == 0) + tickincr = 1; + mtx_unlock_spin(&sched_lock); +} + + /* * Scale the scheduling priority according to the "interactivity" of this * process. @@ -1492,7 +1520,7 @@ sched_fork_ksegrp(struct thread *td, str child->kg_runtime = kg->kg_runtime; child->kg_user_pri = kg->kg_user_pri; sched_interact_fork(child); - kg->kg_runtime += tickincr << 10; + kg->kg_runtime += tickincr; sched_interact_update(kg); } @@ -1615,22 +1643,6 @@ sched_clock(struct thread *td) if (kseq->ksq_assigned) kseq_assign(kseq); /* Potentially sets NEEDRESCHED */ #endif - /* - * sched_setup() apparently happens prior to stathz being set. We - * need to resolve the timers earlier in the boot so we can avoid - * calculating this here. - */ - if (realstathz == 0) { - realstathz = stathz ? stathz : hz; - tickincr = hz / realstathz; - /* - * XXX This does not work for values of stathz that are much - * larger than hz. - */ - if (tickincr == 0) - tickincr = 1; - } - ke = td->td_kse; kg = ke->ke_ksegrp; @@ -1653,7 +1665,7 @@ sched_clock(struct thread *td) * We used a tick charge it to the ksegrp so that we can compute our * interactivity. */ - kg->kg_runtime += tickincr << 10; + kg->kg_runtime += tickincr; sched_interact_update(kg); /* --Multipart=_Fri__30_Sep_2005_08_33_13_+0900_R2RmpAqq+BZmQSkF--