From nobody@FreeBSD.org  Fri Feb 23 01:12:46 2001
Return-Path: <nobody@FreeBSD.org>
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
Subject: libc_r threads library ill-behaved with large HZ kernel setting
X-Send-Pr-Version: www-1.0

>Number:         25300
>Category:       misc
>Synopsis:       libc_r threads library ill-behaved with large HZ kernel setting
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    deischen
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 23 01:20:01 PST 2001
>Closed-Date:    Sun Mar 4 10:11:31 PST 2001
>Last-Modified:  Sun Mar 04 10:12:35 PST 2001
>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:
Responsible-Changed-From-To: freebsd-bugs->deischen 
Responsible-Changed-By: kris 
Responsible-Changed-When: Fri Feb 23 23:55:14 PST 2001 
Responsible-Changed-Why:  
deischen is Mr Threads 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25300 
State-Changed-From-To: open->feedback 
State-Changed-By: deischen 
State-Changed-When: Sun Feb 25 17:07:05 PST 2001 
State-Changed-Why:  
Fix applied to -current. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25300 
State-Changed-From-To: feedback->closed 
State-Changed-By: deischen 
State-Changed-When: Sun Mar 4 10:11:31 PST 2001 
State-Changed-Why:  
Merged to -stable and no feedback from originator in over a week. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25300 
>Unformatted:
