From owner-freebsd-threads@FreeBSD.ORG Mon Mar 1 11:01:46 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4507016A563 for ; Mon, 1 Mar 2004 11:01:46 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F19B143D1F for ; Mon, 1 Mar 2004 11:01:45 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i21J1jbv054148 for ; Mon, 1 Mar 2004 11:01:45 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i21J1j1a054142 for freebsd-threads@freebsd.org; Mon, 1 Mar 2004 11:01:45 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Mar 2004 11:01:45 -0800 (PST) Message-Id: <200403011901.i21J1j1a054142@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 19:01:46 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/19] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] bin/39922 threads [PATCH?] Threaded applications executed w o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] bin/48856 threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] bin/49087 threads Signals lost in programs linked with libc a [2003/04/08] bin/50733 threads buildworld won't build, because of linkin o [2003/05/07] bin/51949 threads thread in accept cannot be cancelled 14 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/25] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] bin/30464 threads pthread mutex attributes -- pshared o [2002/05/02] bin/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 1 12:57:54 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FF3716A4DF for ; Mon, 1 Mar 2004 12:57:54 -0800 (PST) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D8943D41 for ; Mon, 1 Mar 2004 12:57:54 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 5728 invoked from network); 1 Mar 2004 20:57:53 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Mar 2004 20:57:53 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i21KvQ2D075983; Mon, 1 Mar 2004 15:57:46 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: David Xu Date: Mon, 1 Mar 2004 15:55:28 -0500 User-Agent: KMail/1.6 References: <200402271455.38197.jhb@FreeBSD.org> <403FEE22.2040507@freebsd.org> In-Reply-To: <403FEE22.2040507@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403011555.28960.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: threads@freebsd.org Subject: Re: Proper algorithm for return values from sleep X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 20:57:54 -0000 On Friday 27 February 2004 08:25 pm, David Xu wrote: > John Baldwin wrote: > > As part of my sleep queue work, I found that msleep() and the cv_wait() > > functions have differing semantics for return vales. It appears that at > > least some of the early changes KSE made to msleep() were ported to cv's > > but not later cleanups. Specifically, in msleep(), if we are awakened > > while checking for signals but we didn't find a signal, we prefer a > > timeout-related return value over a signal-related value. > > Yes, I think cv and msleep code should be synchronized. > > > Secondly, cv's don't really handle > > td_intrval very well at all. > > It is a bug. :-( > > > It has one hard-coded override for the P_EXIT > > case but that's it. > > I think it should includes P_SINGLE_EXIT, P_WEXIT is set when there is > only one thread in process (see exit1() ). both msleep and cv are > incorrect in the case. > > Are you fixing these bugs ? Well, I'll fix them if I can figure out what the correct algorithm should be. :) Do you think you could sketch it out in psuedo-code? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Mon Mar 1 15:09:38 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 184DB16A558 for ; Mon, 1 Mar 2004 15:09:38 -0800 (PST) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FA6743D2F for ; Mon, 1 Mar 2004 15:09:35 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 25178 invoked from network); 1 Mar 2004 23:09:35 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Mar 2004 23:09:35 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i21N9M2B076770; Mon, 1 Mar 2004 18:09:30 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: "Danny J. Zerkel" Date: Mon, 1 Mar 2004 18:02:51 -0500 User-Agent: KMail/1.6 References: <404399A6.8080303@columbus.rr.com> In-Reply-To: <404399A6.8080303@columbus.rr.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403011802.51028.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: threads@FreeBSD.org cc: current@freebsd.org Subject: Re: Mozilla problems on current -- fix X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 23:09:38 -0000 On Monday 01 March 2004 03:14 pm, Danny J. Zerkel wrote: > Looks like John's sys/kern/kern_thread.c 1.171 broke Mozilla (and > threading in general). He appears to have left out a test that > the sleeping thread is interruptable in one spot: > > --- kern_thread.c.orig Mon Mar 1 15:08:01 2004 > +++ kern_thread.c Mon Mar 1 14:26:30 2004 > @@ -646,7 +646,8 @@ > } else if (TD_ON_SLEEPQ(td2) && > ((td2->td_wchan == &kg->kg_completed) || > (td2->td_wchan == &p->p_siglist && > - (ku->ku_mflags & KMF_WAITSIGEVENT)))) { > + (ku->ku_mflags & KMF_WAITSIGEVENT))) && > + (td2->td_flags & TDF_SINTR)) { > sleepq_abort(td2); > } else { > ku->ku_flags |= KUF_DOUPCALL; > > This change fixes my Mozilla hangs and other panics on current. This should not matter. This is the only place that doesn't check TDF_SINTR, true, but it should always be set in these cases. First, look in kern_thread.c where we msleep() on these addresses (p_siglist and kg_completed): if (!(p->p_flag & P_SIGEVENT) && !(ku->ku_flags & KUF_DOUPCALL)) error = msleep(&p->p_siglist, &p->p_mtx, PPAUSE| PCATCH, "ksesigwait", (uap->timeout ? tvtohz(&tv) : 0)); p->p_flag &= ~P_SIGEVENT; Note that PCATCH is set. error = msleep(&kg->kg_completed, &p->p_mtx, PPAUSE|PCATCH, "kserel", (uap->timeout ? tvtohz(&tv) : 0)); kg->kg_upsleeps--; Again, PCATCH is set. Now onto kern_synch.c and msleep(): catch = priority & PCATCH; ... sq = sleepq_lookup(ident); ... sleepq_add(sq, ident, mtx, wmesg, 0); if (timo) sleepq_set_timeout(sq, ident, timo); if (catch) { sig = sleepq_catch_signals(ident); if (sig == 0 && !TD_ON_SLEEPQ(td)) { mtx_lock_spin(&sched_lock); td->td_flags &= ~TDF_SINTR; mtx_unlock_spin(&sched_lock); catch = 0; } } else sig = 0; ... sleepq_wait_foo(ident); Thus, we see that if PCATCH is set, we call sleepq_add() and then sleepq_catch_signals(). Bah, I see. Only the sleep queue lock is atomic for the whole operation and not sched_lock. While your patch might fix the assertion for this KSE case, there might be a larger set or problems with the race here, which is that sched_lock can be dropped in between td_wchan being set and TDF_SINTR being set. I.e, if you get an abort in between the sleepq_add() and sleepq_catch_signals() and just use sched_lock it will get lost when it shouldn't. For signals, I think the call to cursig() will still work ok. I'm not sure if sleepq_catch_signals() calls anything that checks for KUF_DOUPCALL. Let me check. Ugh, this code is too hard to follow. I have no idea if this is actually safe or not. :( I can commit the above as a band-aid I guess. I don't know why the KSE code doesn't just use a wakeup here, the sleeps are in top-level functions and not buried deep. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Mon Mar 1 15:23:46 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5C3816A4CE; Mon, 1 Mar 2004 15:23:46 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B1C43D39; Mon, 1 Mar 2004 15:23:46 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i21NNjbv087209; Mon, 1 Mar 2004 15:23:46 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <4043C548.4080608@freebsd.org> Date: Tue, 02 Mar 2004 07:20:40 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200402271455.38197.jhb@FreeBSD.org> <403FEE22.2040507@freebsd.org> <200403011555.28960.jhb@FreeBSD.org> In-Reply-To: <200403011555.28960.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: Proper algorithm for return values from sleep X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 23:23:46 -0000 John Baldwin wrote: > On Friday 27 February 2004 08:25 pm, David Xu wrote: > >>John Baldwin wrote: >> >>>As part of my sleep queue work, I found that msleep() and the cv_wait() >>>functions have differing semantics for return vales. It appears that at >>>least some of the early changes KSE made to msleep() were ported to cv's >>>but not later cleanups. Specifically, in msleep(), if we are awakened >>>while checking for signals but we didn't find a signal, we prefer a >>>timeout-related return value over a signal-related value. >> >>Yes, I think cv and msleep code should be synchronized. >> >> >>>Secondly, cv's don't really handle >>>td_intrval very well at all. >> >>It is a bug. :-( >> >> >>>It has one hard-coded override for the P_EXIT >>>case but that's it. >> >>I think it should includes P_SINGLE_EXIT, P_WEXIT is set when there is >>only one thread in process (see exit1() ). both msleep and cv are >>incorrect in the case. >> >>Are you fixing these bugs ? > > > Well, I'll fix them if I can figure out what the correct algorithm should > be. :) Do you think you could sketch it out in psuedo-code? > I think msleep and cv code may only care if it should be blocked or not, but don't care which signal should be returned from sleepq, sleepq would return zero, EINTR, EAGAIN or EWOULDBLOCK, TDF_INTERRUPT should be handled in sleepq_catch_signals(), and the function may only return above values. I am busy at thread debugger code, and don't have time to fix it. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 1 21:21:47 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BFD816A4CE for ; Mon, 1 Mar 2004 21:21:47 -0800 (PST) Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au [203.22.124.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685F443D2D for ; Mon, 1 Mar 2004 21:21:46 -0800 (PST) (envelope-from grehan@freebsd.org) Received: from freebsd.org (CPE-30-165.dsl.onthenet.net [203.144.30.165]) i225LiZG082325 for ; Tue, 2 Mar 2004 15:21:45 +1000 (EST) (envelope-from grehan@freebsd.org) Message-ID: <40441A7E.7000805@freebsd.org> Date: Tue, 02 Mar 2004 15:24:14 +1000 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: threads stress test X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 05:21:47 -0000 I've been using the ping-pong test program described in: http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf to test out Suleiman Souhal's PPC libthr patches. I just took out sledge (AMD64) with this when linking against libpthread and running with '-v -i 10000'. Not sure if it happens on i386, but maybe KSE developers might want to give it a try. Source is at: http://www.freebsd.org/~grehan/pp.c WRT libthr, ctl-C from the shell doesn't seem to get through when running this program (verified on panther/sparc64), although libpthread does the right thing. Oops, just took out panther when running with libthr after doing some libpthread testing. Definitely worth a try ! later, Peter. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 1 21:39:16 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE37416A4CE; Mon, 1 Mar 2004 21:39:16 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94D3043D1D; Mon, 1 Mar 2004 21:39:14 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i225dDbN011589; Tue, 2 Mar 2004 00:39:14 -0500 (EST) Date: Tue, 2 Mar 2004 00:39:13 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Peter Grehan In-Reply-To: <40441A7E.7000805@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: threads stress test X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 05:39:17 -0000 On Tue, 2 Mar 2004, Peter Grehan wrote: > I've been using the ping-pong test program described in: > > http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf > > to test out Suleiman Souhal's PPC libthr patches. FYI, you can also build libpthread in 1:1 mode and won't need a fully working set of user context switch functions. Both alpha and sparc64 seem to limp by with 1:1 libpthread. > I just took out sledge (AMD64) with this when linking against > libpthread and running with '-v -i 10000'. Not sure if it happens > on i386, but maybe KSE developers might want to give it a try. > Source is at: > > http://www.freebsd.org/~grehan/pp.c > > WRT libthr, ctl-C from the shell doesn't seem to get through when > running this program (verified on panther/sparc64), although libpthread > does the right thing. > > Oops, just took out panther when running with libthr after doing > some libpthread testing. Definitely worth a try ! I can also take out panther running a very simple libpthread (in 1:1 mode) test (libpthread/test/sigwait_d.c). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 1 21:54:18 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 445A816A4CE for ; Mon, 1 Mar 2004 21:54:18 -0800 (PST) Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au [203.22.124.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A29DB43D1F for ; Mon, 1 Mar 2004 21:54:17 -0800 (PST) (envelope-from grehan@freebsd.org) Received: from freebsd.org (CPE-30-165.dsl.onthenet.net [203.144.30.165]) i225sGZG082476; Tue, 2 Mar 2004 15:54:16 +1000 (EST) (envelope-from grehan@freebsd.org) Message-ID: <4044221D.1060904@freebsd.org> Date: Tue, 02 Mar 2004 15:56:45 +1000 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: threads stress test X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 05:54:18 -0000 > I can also take out panther running a very simple libpthread (in 1:1 > mode) test (libpthread/test/sigwait_d.c). Happy to say that PPC libthr works fine with this. Looking forward to trying it out on libpthread. later, Peter. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 1 23:18:03 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3BC816A4CE; Mon, 1 Mar 2004 23:18:03 -0800 (PST) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A62243D2F; Mon, 1 Mar 2004 23:18:01 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FH4K6S9V; Tue, 2 Mar 2004 15:17:58 +0800 Message-ID: <4044354B.3080005@freebsd.org> Date: Tue, 02 Mar 2004 15:18:35 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Grehan References: <40441A7E.7000805@freebsd.org> In-Reply-To: <40441A7E.7000805@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: threads stress test X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 07:18:03 -0000 Peter Grehan wrote: > I've been using the ping-pong test program described in: > > http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf > > to test out Suleiman Souhal's PPC libthr patches. > > I just took out sledge (AMD64) with this when linking against > libpthread and running with '-v -i 10000'. Not sure if it happens > on i386, but maybe KSE developers might want to give it a try. I ran it on an old Celeron 500Mhz (Pentium II class): ------------------------------------------------- 1. Process scope thread (libpthread) ./pp -s process -v PING-PONG CONFIGURATION: target (-i) = 1000000 ntables (-n) = 1 sleepms (-z) = 0 pthread_scope (-s) = process pthread_process (-p) = private concurrency (-c) = 0 stacksize (-S) = 0 2 threads initialised in 1ms 1 games completed in 9713ms --------------------------------------------------- 2. System scope thread (libpthread) ./pp -s system -v PING-PONG CONFIGURATION: target (-i) = 1000000 ntables (-n) = 1 sleepms (-z) = 0 pthread_scope (-s) = system pthread_process (-p) = private concurrency (-c) = 0 stacksize (-S) = 0 2 threads initialised in 1ms 1 games completed in 25630ms ------------------------------------------------- 3. With libc_r ./pp_r -v PING-PONG CONFIGURATION: target (-i) = 1000000 ntables (-n) = 1 sleepms (-z) = 0 pthread_scope (-s) = process pthread_process (-p) = private concurrency (-c) = 0 stacksize (-S) = 0 2 threads initialised in 0ms 1 games completed in 8266ms ----------------------------------------------- 4. With libthr ./ppthr -v PING-PONG CONFIGURATION: target (-i) = 1000000 ntables (-n) = 1 sleepms (-z) = 0 pthread_scope (-s) = process pthread_process (-p) = private concurrency (-c) = 0 stacksize (-S) = 0 2 threads initialised in 1ms 1 games completed in 88306ms -------------------------------------------- Interesting article, it seems libc_r is still fastest in the test. ;-) > > Source is at: > > http://www.freebsd.org/~grehan/pp.c > > WRT libthr, ctl-C from the shell doesn't seem to get through when > running this program (verified on panther/sparc64), although libpthread > does the right thing. > > Oops, just took out panther when running with libthr after doing > some libpthread testing. Definitely worth a try ! > > later, > > Peter. > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to > "freebsd-threads-unsubscribe@freebsd.org" > > From owner-freebsd-threads@FreeBSD.ORG Wed Mar 3 00:14:29 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5864816A4CE for ; Wed, 3 Mar 2004 00:14:29 -0800 (PST) Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au [203.22.124.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C321943D49 for ; Wed, 3 Mar 2004 00:14:28 -0800 (PST) (envelope-from grehan@freebsd.org) Received: from freebsd.org (CPE-30-165.dsl.onthenet.net [203.144.30.165]) i238ERZG085975 for ; Wed, 3 Mar 2004 18:14:27 +1000 (EST) (envelope-from grehan@freebsd.org) Message-ID: <40459478.9060702@freebsd.org> Date: Wed, 03 Mar 2004 18:16:56 +1000 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2004 08:14:29 -0000 Here's the comment I currently have in libpthread/.../powerpc/context.S: * XXX XXX * Floating-point is a big issue. Since there's no way to determine * if the caller has used FP, all volatile register need to be saved. * If FP hasn't been used, this results in a lazy FP exception in * the kernel and from that point on FP is always switched in/out * for the thread, which may be a big performance drag for the system. * An alternative is to use the the getcontext system call, which * will do the right thing for floating point but will save all * registers rather than the caller-saved subset, and has the overhead * of a syscall. * Maybe another option would be to give a light-weight way for a * thread to determine if FP is in used: perhaps a syscall that * returns this info immediately in the asm traphandler, or an * OSX-style read-only per-thread page with a flag to indicate FP state. Any opinions ? I noticed the alpha/sparc64 routines don't save FP. later, Peter. From owner-freebsd-threads@FreeBSD.ORG Wed Mar 3 06:16:30 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6E7516A4CE; Wed, 3 Mar 2004 06:16:30 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E80843D45; Wed, 3 Mar 2004 06:16:30 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i23EGUbN020742; Wed, 3 Mar 2004 09:16:30 -0500 (EST) Date: Wed, 3 Mar 2004 09:16:30 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Peter Grehan In-Reply-To: <40459478.9060702@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2004 14:16:31 -0000 On Wed, 3 Mar 2004, Peter Grehan wrote: > Here's the comment I currently have in libpthread/.../powerpc/context.S: > > * XXX XXX > * Floating-point is a big issue. Since there's no way to determine > * if the caller has used FP, all volatile register need to be saved. > * If FP hasn't been used, this results in a lazy FP exception in > * the kernel and from that point on FP is always switched in/out > * for the thread, which may be a big performance drag for the system. > * An alternative is to use the the getcontext system call, which > * will do the right thing for floating point but will save all > * registers rather than the caller-saved subset, and has the overhead > * of a syscall. > * Maybe another option would be to give a light-weight way for a > * thread to determine if FP is in used: perhaps a syscall that > * returns this info immediately in the asm traphandler, or an > * OSX-style read-only per-thread page with a flag to indicate FP state. > > Any opinions ? I noticed the alpha/sparc64 routines don't save FP. You don't need to save floating point registers when saving the context from userland. The userland _thr_getcontext() function is called as a result of an application calling pthread_yield(), sleep(), nanosleep(), etc (yielding/sleeping calls), or by something that blocks in userland like pthread_mutex_lock(), pthread_cond_wait(), low-level libc/libpthread locks, etc. Look at the i386 thr_getcontext(); it only needs to save the FP control word. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Mar 3 15:26:38 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23BD116A4DB for ; Wed, 3 Mar 2004 15:26:38 -0800 (PST) Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au [203.22.124.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EE3443D2F for ; Wed, 3 Mar 2004 15:26:37 -0800 (PST) (envelope-from grehan@freebsd.org) Received: from freebsd.org (CPE-30-38.dsl.onthenet.net [203.144.30.38]) i23NQZZG087368; Thu, 4 Mar 2004 09:26:36 +1000 (EST) (envelope-from grehan@freebsd.org) Message-ID: <40466A3F.5070904@freebsd.org> Date: Thu, 04 Mar 2004 09:29:03 +1000 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2004 23:26:38 -0000 >> Any opinions ? I noticed the alpha/sparc64 routines don't save FP. > > You don't need to save floating point registers when saving the > context from userland. But why is that any different from having to save non-volatile integer registers ? For instance, on PPC, gp regs 14-31, and also fp regs 14-31, need to be saved by the callee if used since they're non-volatile across function calls. > Look at the i386 thr_getcontext(); it only needs to save the FP > control word. Yes, but I thought the i386 FP calling convention was that all FP registers were volatile across calls, so all were preserved by the callee. later, Peter. From owner-freebsd-threads@FreeBSD.ORG Wed Mar 3 18:34:02 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ED4C16A4CF for ; Wed, 3 Mar 2004 18:34:02 -0800 (PST) Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au [203.22.124.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8B0443D2D for ; Wed, 3 Mar 2004 18:34:01 -0800 (PST) (envelope-from grehan@freebsd.org) Received: from freebsd.org (CPE-30-38.dsl.onthenet.net [203.144.30.38]) i242Y0ZG088118; Thu, 4 Mar 2004 12:34:00 +1000 (EST) (envelope-from grehan@freebsd.org) Message-ID: <4046962C.4090409@freebsd.org> Date: Thu, 04 Mar 2004 12:36:28 +1000 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org References: <40466A3F.5070904@freebsd.org> In-Reply-To: <40466A3F.5070904@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 02:34:02 -0000 > Yes, but I thought the i386 FP calling convention was that all > FP registers were volatile across calls, so all were preserved > by the callee. Oops, I meant 'caller'... From owner-freebsd-threads@FreeBSD.ORG Wed Mar 3 19:36:57 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF21316A4CE; Wed, 3 Mar 2004 19:36:57 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D06043D1D; Wed, 3 Mar 2004 19:36:57 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.10/8.12.10) with ESMTP id i243avOE002541; Wed, 3 Mar 2004 19:36:57 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) i243av0O000793; Wed, 3 Mar 2004 19:36:57 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i243avGO000792; Wed, 3 Mar 2004 19:36:57 -0800 (PST) (envelope-from marcel) Date: Wed, 3 Mar 2004 19:36:57 -0800 From: Marcel Moolenaar To: Peter Grehan Message-ID: <20040304033657.GA721@dhcp01.pn.xcllnt.net> References: <40466A3F.5070904@freebsd.org> <4046962C.4090409@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4046962C.4090409@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-threads@freebsd.org Subject: Re: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 03:36:57 -0000 On Thu, Mar 04, 2004 at 12:36:28PM +1000, Peter Grehan wrote: > > Yes, but I thought the i386 FP calling convention was that all > >FP registers were volatile across calls, so all were preserved > >by the callee. > > Oops, I meant 'caller'... Yes. You need to save the FP registers on PPC that are callee saved. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-threads@FreeBSD.ORG Wed Mar 3 20:36:20 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA43016A4CE; Wed, 3 Mar 2004 20:36:20 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73A5943D2F; Wed, 3 Mar 2004 20:36:20 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i244aJbN023362; Wed, 3 Mar 2004 23:36:19 -0500 (EST) Date: Wed, 3 Mar 2004 23:36:19 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Peter Grehan In-Reply-To: <40466A3F.5070904@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 04:36:20 -0000 On Thu, 4 Mar 2004, Peter Grehan wrote: > >> Any opinions ? I noticed the alpha/sparc64 routines don't save FP. > > > > You don't need to save floating point registers when saving the > > context from userland. > > But why is that any different from having to save non-volatile > integer registers ? For instance, on PPC, gp regs 14-31, and also > fp regs 14-31, need to be saved by the callee if used since they're > non-volatile across function calls. > > > Look at the i386 thr_getcontext(); it only needs to save the FP > > control word. > > Yes, but I thought the i386 FP calling convention was that all > FP registers were volatile across calls, so all were preserved > by the callee. Yes, but how do you generate code that does: double x, y; ... x = y * 1.5 * sqrt(2.25) - 3.15 + pthread_mutex_lock(&m) + 1.25; ... If on the other hand: x = y * 1.5 - sqrt(2.25); pthread_mutex_lock(&m); x = x + 2.0; requires FP registers to be saved, then so be it. I don't know anything about PPC... -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Mar 3 21:12:06 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A90D416A4CF for ; Wed, 3 Mar 2004 21:12:06 -0800 (PST) Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au [203.22.124.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24E6543D2F for ; Wed, 3 Mar 2004 21:12:06 -0800 (PST) (envelope-from grehan@freebsd.org) Received: from freebsd.org (CPE-30-38.dsl.onthenet.net [203.144.30.38]) i245C4ZG088656; Thu, 4 Mar 2004 15:12:05 +1000 (EST) (envelope-from grehan@freebsd.org) Message-ID: <4046BB39.9050608@freebsd.org> Date: Thu, 04 Mar 2004 15:14:33 +1000 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 05:12:06 -0000 > how do you generate code that does: > > double x, y; > > ... > x = y * 1.5 * sqrt(2.25) - 3.15 + pthread_mutex_lock(&m) + 1.25; Substitute integers for float and it's exactly the same problem and handled in the same way: the caller saves registers it is using for intermediate results prior to the mutex_lock and restores them on return according to the calling convention. > I don't know anything about PPC... It's generic RISC, similar to Alpha in terms of register usage. That's what made me wonder about not saving FP state in the Alpha code, but I now think that's a requirement if there are 2 or more threads using FP. That will be a big performance hit as per my routine comments so I'll do some experiments to see how severe it is and whether it can be alleviated. later, Peter. From owner-freebsd-threads@FreeBSD.ORG Wed Mar 3 22:43:12 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6D3816A4CE; Wed, 3 Mar 2004 22:43:12 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81C2643D39; Wed, 3 Mar 2004 22:43:12 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i246hBbN024491; Thu, 4 Mar 2004 01:43:11 -0500 (EST) Date: Thu, 4 Mar 2004 01:43:11 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Peter Grehan In-Reply-To: <4046BB39.9050608@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 06:43:13 -0000 On Thu, 4 Mar 2004, Peter Grehan wrote: > > how do you generate code that does: > > > > double x, y; > > > > ... > > x = y * 1.5 * sqrt(2.25) - 3.15 + pthread_mutex_lock(&m) + 1.25; > > Substitute integers for float and it's exactly the same problem > and handled in the same way: the caller saves registers it is using > for intermediate results prior to the mutex_lock and restores them > on return according to the calling convention. So if the caller saves the registers before pthread_mutex_lock(), why do they also need to be saved by _thr_getcontext (which may be a result of pthread_mutex_lock() in this example)? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Mar 3 23:28:42 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 081CE16A4CE for ; Wed, 3 Mar 2004 23:28:42 -0800 (PST) Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au [203.22.124.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 787FD43D39 for ; Wed, 3 Mar 2004 23:28:41 -0800 (PST) (envelope-from grehan@freebsd.org) Received: from freebsd.org (CPE-30-38.dsl.onthenet.net [203.144.30.38]) i247SdZG089171; Thu, 4 Mar 2004 17:28:40 +1000 (EST) (envelope-from grehan@freebsd.org) Message-ID: <4046DB3B.9000604@freebsd.org> Date: Thu, 04 Mar 2004 17:31:07 +1000 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 07:28:42 -0000 > So if the caller saves the registers before pthread_mutex_lock(), why > do they also need to be saved by _thr_getcontext (which may be a > result of pthread_mutex_lock() in this example)? I was a bit vague. Here's relevant text from the SVR4 PPC ABI: "Registers r1, r14 through r31, and f14 through f31 are nonvolatile; that is, they "belong" to the calling function. A called function shall save these registers values before it changes them, restoring their values before it returns. Registers r0, r3 through r12, f0 through f13, and the special purpose registers CTR and XER are volatile; that is, they are not preserved across function calls." and: "r3 through r10 and f1 through f8: These sets of volatile registers may be modified across function invocations and shall therefore be presumed by the calling function to be destroyed. They are used for passing parameters to the called function; see Parameter Passing in this chapter. In addition, registers r3, r4, and f1 are used to return values from the called function, as described in Return Values." So as a context-save function, you have to assume that f14-31 are being used by the caller and save them. Problem is, these regs are 64-bits on PPC, touching them will cause an FP trap and from then on force full kernel FP save/restore for that proc's td, which is big performance hit for the majority of non-FP threads userland threads. The Altivec register file is a bit better since it has a register to inform context switch code which of the 32 128-bit registers are in use. later, Peter. From owner-freebsd-threads@FreeBSD.ORG Thu Mar 4 07:28:20 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A94416A4CE; Thu, 4 Mar 2004 07:28:20 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BB4143D53; Thu, 4 Mar 2004 07:28:20 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i24FSJbN028944; Thu, 4 Mar 2004 10:28:19 -0500 (EST) Date: Thu, 4 Mar 2004 10:28:19 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Peter Grehan In-Reply-To: <4046DB3B.9000604@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: User-space context switch and floating-point X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2004 15:28:20 -0000 On Thu, 4 Mar 2004, Peter Grehan wrote: > > So if the caller saves the registers before pthread_mutex_lock(), why > > do they also need to be saved by _thr_getcontext (which may be a > > result of pthread_mutex_lock() in this example)? > > I was a bit vague. Here's relevant text from the SVR4 PPC ABI: > > "Registers r1, r14 through r31, and f14 through f31 are nonvolatile; > that is, they "belong" to the calling function. A called function shall > save these registers values before it changes them, restoring their > values before it returns. Registers r0, r3 through r12, f0 through f13, > and the special purpose registers CTR and XER are volatile; that is, > they are not preserved across function calls." > > and: > > "r3 through r10 and f1 through f8: > These sets of volatile registers may be modified across function > invocations and shall therefore be presumed by the calling function to > be destroyed. They are used for passing parameters to the called > function; see Parameter Passing in this chapter. In addition, registers > r3, r4, and f1 are used to return values from the called function, as > described in Return Values." > > So as a context-save function, you have to assume that f14-31 are being > used by the caller and save them. Problem is, these regs are 64-bits > on PPC, touching them will cause an FP trap and from then on force > full kernel FP save/restore for that proc's td, which is big performance > hit for the majority of non-FP threads userland threads. Yes, for the first time. Thread switches that follow won't cause the trap, until the process (kernel thread really) gets swapped out/interrupted. I think the x86 is similar when saving/restoring the FP control world. > The Altivec register file is a bit better since it has a register to > inform context switch code which of the 32 128-bit registers are in > use. -- Dan Eischen