From nobody@FreeBSD.org  Thu Oct 10 01:15:28 2002
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D5AC237B401
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 10 Oct 2002 01:15:28 -0700 (PDT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 956C943EAF
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 10 Oct 2002 01:15:28 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.6/8.12.6) with ESMTP id g9A8FO7R004683
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 10 Oct 2002 01:15:24 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.6/8.12.6/Submit) id g9A8FOh8004682;
	Thu, 10 Oct 2002 01:15:24 -0700 (PDT)
Message-Id: <200210100815.g9A8FOh8004682@www.freebsd.org>
Date: Thu, 10 Oct 2002 01:15:24 -0700 (PDT)
From: Jian Tang <t_fisher@163.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: abnormal CPU useage when use pthread_mutex
X-Send-Pr-Version: www-1.0

>Number:         43887
>Category:       kern
>Synopsis:       abnormal CPU useage when use pthread_mutex
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-threads
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 10 01:20:01 PDT 2002
>Closed-Date:    Wed Feb 04 07:47:26 PST 2004
>Last-Modified:  Wed Feb 04 07:47:26 PST 2004
>Originator:     Jian Tang
>Release:        FreeBSD 4.3
>Organization:
CongXing
>Environment:
$ uname -a
FreeBSD cvs.risson.com 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Tue Nov  6 12:53:47 CST 2001     tang@cvs.risson.com:/usr/src/sys
/compile/kernel  i386
>Description:
I have a small code to test the efficiency of the pthread_mutext.
#include <unistd.h>
#include <pthread.h>
#include <errno.h>

int main(int argc,char** argv)
{
    pthread_mutex_t mutex;
    long i,j;
    j =0;
    pthread_mutex_init(&mutex,NULL);
    while(1)
    {
        pthread_mutex_lock(&mutex);
        i = j*j;
        j++;
        pthread_mutex_unlock(&mutex);

        printf("i=%ld\n",i);
        if(usleep(800)== -1)
            printf("usleep fail. %s",strerror(errno));
    }
    return 0;
}

When I ran this program, I found that the usage of CPU is very high. 
CPU states: 25.3% user,  0.0% nice, 71.6% system,  0.4% interrupt,  2.7% idle

To reduce the usage of CPU,I added the time of usleep. I found that when the time of usleep is large than 1000,the status of cpu came back normal.
CPU states:  0.0% user,  0.0% nice,  1.6% system,  0.4% interrupt, 98.1% idle

I guess this problem is caused by the scheduler of thread. 
>How-To-Repeat:

>Fix:
     
>Release-Note:
>Audit-Trail:

From: Alexander Popkov <voodoo_alex@mail.ru>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Jian Tang <t_fisher@163.com>
Subject: Re: kern/43887: abnormal CPU useage when use pthread_mutex
Date: Thu, 10 Oct 2002 12:55:27 +0400

 Hello Jian,
 
 Thursday, October 10, 2002, 12:15:24 PM, you wrote:
 
 JT> When I ran this program, I found that the usage of CPU is very high. 
 JT> CPU states: 25.3% user,  0.0% nice, 71.6% system,  0.4% interrupt,  2.7% idle
 
 JT> To reduce the usage of CPU,I added the time of usleep. I found that when the time of usleep is large than 1000,the status of cpu came back normal.
 JT> CPU states:  0.0% user,  0.0% nice,  1.6% system,  0.4% interrupt, 98.1% idle
 
 JT> I guess this problem is caused by the scheduler of thread. 
 
 Yes.
 FreeBSD 4.6 - too.
 
 [voodoo@alpha tmp]$ uname -a
 FreeBSD alpha.millenniumrise.ru 4.6-STABLE FreeBSD 4.6-STABLE #4: Thu Aug  8 17:01:06 MSD 2002     root@damn.millenniumrise.ru:/usr/obj/usr/src/sys/ALPHA  i386
 
 with usleep(800):
 --------------------------------
 CPU states: 25.3% user,  0.0% nice, 70.8% system,  3.1% interrupt,  0.8% idle
 
   PID USERNAME  PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
  4075 voodoo     39   0  1088K   564K RUN      0:09 71.58% 32.32% a.out
 
 with usleep(1100):
 --------------------------------
 CPU states:  4.3% user,  0.0% nice,  1.2% system,  0.8% interrupt, 93.8% idle
 
   PID USERNAME  PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
  4133 voodoo      2   0  1088K   564K RUN      0:00  0.00%  0.00% a.out
 
 -- 
 Best regards,
  Alexander                            mailto:voodoo_alex@mail.ru
 
 

From: "Dorr H. Clark" <dclark@applmath.scu.edu>
To: freebsd-gnats-submit@FreeBSD.org, t_fisher@163.com
Cc:  
Subject: Re: kern/43887: abnormal CPU useage when use pthread_mutex
Date: Wed, 28 May 2003 10:41:35 -0700

 This bug states that a CPU spike is evident when a small test program
 is executed.  We believe that this behavior is a side effect of 
 the FreeBSD threads implementation, and may perhaps only be 
 exhibited in small test programs or when larger programs
 match the same condition of calling usleep with values under
 1 msec at a point when no other threads are ready to run.
 
 Based on the original intent of the user, we believe 
 they should alter their test program to account for the FreeBSD
 threads implementation.
 
 In FreeBSD, the pthread implementation is as a user-level thread
 package,
 in other words, all threads execute in the context of a single process, 
 and the thread scheduler is hidden in the threaded version of libc.
 
 usleep (defined in src/lib/libc/gen/usleep.c) is a wrapper for 
 _nanosleep (src/lib/libc_r/uthread/uthread_nanosleep.c),
 which allows the thread scheduler to gain execution control.
 _thread_kern_scheduler then invokes thread_kern_poll which
 eventually resolves to the system call poll().  In the current
 threads implementation, poll() is invoked with a timeout granularity
 in the milliseconds.  Thus for short timeout values, poll returns
 almost immediately and the process spins around in the thread
 scheduler looking for somebody to run.
 
 Note if the sleep value is increased beyond the 1 ms threshold,
 then poll calls tsleep, throwing the entire process on the mercy
 of the scheduler.  In our experiments, a typical sleep time 
 was 20 msec, indicating the expiration of multiple ticks.
 
 The test program in the original bug was attempting to measure 
 the efficiency of pthread_mutex operations, but the code as written 
 will have CPU measurements dominated by the usleep call
 and the pthread internals.  A different approach is needed
 to serve the original purpose.
 
 If the 43887 behavior is intolerable, there are two possible approaches,
 either wait for a pthreads implementation on top of the kernel threads 
 in FreeBSD 5.0 or install the linuxthreads port, which simulates the
 Linux 
 way of handling threads as separate processes. 
 
 Konstantin Svist, engineer
 Dorr H. Clark, advisor
 COEN 284 - Operating Systems Case Study 
 Santa Clara University, 
 Santa Clara CA.
Responsible-Changed-From-To: freebsd-bugs->freebsd-threads 
Responsible-Changed-By: kris 
Responsible-Changed-When: Sat Jul 12 18:39:10 PDT 2003 
Responsible-Changed-Why:  
Assign to threads mailing list 

http://www.freebsd.org/cgi/query-pr.cgi?pr=43887 

From: Craig Rodrigues <rodrigc@crodrigues.org>
To: freebsd-gnats-submit@freebsd.org
Cc: t_fisher@163.com
Subject: Re: kern/43887: abnormal CPU useage when use pthread_mutex
Date: Mon, 2 Feb 2004 17:05:28 -0500

 Hi,
 
 I don't think that this PR is very meaningful, and should be closed.
 
 This PR basically complains about the following code
 consuming too much CPU if you take out the usleep().
 
 =====================================================================
 #include <unistd.h>
 #include <pthread.h>
 #include <errno.h>
 
 int main(int argc,char** argv)
 {
     pthread_mutex_t mutex;
     long i,j;
     j =0;
     pthread_mutex_init(&mutex,NULL);
     while(1)
     {
         pthread_mutex_lock(&mutex);
         i = j*j;
         j++;
         pthread_mutex_unlock(&mutex);
 
         printf("i=%ld\n",i);
         if(usleep(800)== -1)
             printf("usleep fail. %s",strerror(errno));
     }
     return 0;
 }
 =====================================================================
 
 Well, this code isn't doing too much, except for spinning
 in a tight loop.  I think this PR should be closed. 
 
 
 -- 
 Craig Rodrigues        
 rodrigc@crodrigues.org
State-Changed-From-To: open->closed 
State-Changed-By: deischen 
State-Changed-When: Wed Feb 4 07:45:26 PST 2004 
State-Changed-Why:  
The resolution of the scheduling clock in libc_r is msecs since poll 
is used as the underlying event mechanism.  Use libpthread or libthr 
if you desire something else. 

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