From owner-freebsd-bugs  Fri Feb 23  1:20: 9 2001
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id BCF9D37B67D
	for <freebsd-bugs@hub.freebsd.org>; Fri, 23 Feb 2001 01:20:01 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f1N9K1k46878;
	Fri, 23 Feb 2001 01:20:01 -0800 (PST)
	(envelope-from gnats)
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 417FA37B401
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 23 Feb 2001 01:12:46 -0800 (PST)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f1N9Ckh46200;
	Fri, 23 Feb 2001 01:12:46 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200102230912.f1N9Ckh46200@freefall.freebsd.org>
Date: Fri, 23 Feb 2001 01:12:46 -0800 (PST)
From: pavel@alum.mit.edu
To: freebsd-gnats-submit@FreeBSD.org
X-Send-Pr-Version: www-1.0
Subject: misc/25300: libc_r threads library ill-behaved with large HZ kernel setting
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>Number:         25300
>Category:       misc
>Synopsis:       libc_r threads library ill-behaved with large HZ kernel setting
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 23 01:20:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Tom Pavel
>Release:        4.2-RELEASE
>Organization:
Network Physics
>Environment:
FreeBSD caravan.fractal.networkphysics.com 4.2-RELEASE FreeBSD NP-20010110  i386

>Description:
Due to some specialized kernel driver requirements, we are running 
with very high values of HZ (10000 or 30000).  This works OK for us
in the kernel, but causes problem with threaded applications linked 
against libc_r.  The problem comes from the garbage collector thread, 
which runs at whatever rate sysctl(kern.clockrate) reports.  In our 
case, with the very high HZ, this means libc_r tries to schedule an 
itimer with a 30 us period.  As a result, 50% or more of the available 
user CPU is consumed by the gc thread, and any threaded program runs 
some x2 slower.

As far as I can tell, there is no need for the gc thread to run so 
frequently.  The TIMESLICE_USEC constant indicates that 10-20 ms is 
the most resolution required in the libc_r threading kernel.  My 
proposed fix is to cap off _clock_res_usec at a max of CLOCK_RES_USEC.
This change seems to work fine for us, with mysqld for example.
>How-To-Repeat:
Set HZ to 10000 in the kernel, and compare run times for any program
or benchmark that is linked against libc_r (and uses threads).
>Fix:
--- lib/libc_r/uthread/uthread_init.c.ORIG      Wed Feb 21 21:31:31 2001
+++ lib/libc_r/uthread/uthread_init.c   Wed Feb 21 21:36:59 2001
@@ -336,7 +336,11 @@
                mib[1] = KERN_CLOCKRATE;
                len = sizeof (struct clockinfo);
                if (sysctl(mib, 2, &clockinfo, &len, NULL, 0) == 0)
-                       _clock_res_usec = clockinfo.tick;
+                       /* NPMOD - use larger of clockinfo.tick or
+                          CLOCK_RES_USEC (=10ms) for the uthreads
+                          base tick (pavel - 21-Feb-2001):*/
+                       _clock_res_usec = (clockinfo.tick > CLOCK_RES_USEC) ? 
+                         clockinfo.tick : CLOCK_RES_USEC;
 
                /* Get the table size: */
                if ((_thread_dtablesize = getdtablesize()) < 0) {

>Release-Note:
>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message