Date: Wed, 28 May 2003 11:40:12 -0700 (PDT) From: "Dorr H. Clark" <dclark@applmath.scu.edu> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/43887: abnormal CPU useage when use pthread_mutex Message-ID: <200305281840.h4SIeCuG011497@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/43887; it has been noted by GNATS. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305281840.h4SIeCuG011497>