Bug 25300

Summary: libc_r threads library ill-behaved with large HZ kernel setting
Product: Base System Reporter: pavel <pavel>
Component: miscAssignee: Daniel Eischen <deischen>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.2-RELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description pavel 2001-02-23 09:20:01 UTC 
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).
Comment 1 Kris Kennaway freebsd_committer freebsd_triage 2001-02-24 07:55:14 UTC 
Responsible Changed
From-To: freebsd-bugs->deischen

deischen is Mr Threads
Comment 2 Daniel Eischen freebsd_committer freebsd_triage 2001-02-26 01:07:05 UTC 
State Changed
From-To: open->feedback

Fix applied to -current.
Comment 3 Daniel Eischen freebsd_committer freebsd_triage 2001-03-04 18:11:31 UTC 
State Changed
From-To: feedback->closed

Merged to -stable and no feedback from originator in over a week.