From owner-freebsd-threads@FreeBSD.ORG Sun Dec 7 18:59:40 2003 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 D070716A4CF; Sun, 7 Dec 2003 18:59:40 -0800 (PST) Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A55DD43FE0; Sun, 7 Dec 2003 18:59:36 -0800 (PST) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (excluster2.maxwell.syr.edu [128.230.129.231]) by maxwell.syr.edu (8.12.10/8.9.1) with ESMTP id hB82xXo2094425; Sun, 7 Dec 2003 21:59:33 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Dec 2003 21:59:36 -0500 Message-ID: <32A8B2CB12BFC84D8D11D872C787AA9A02B1F7D9@EXCHANGE.forest.maxwell.syr.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: KSE system scope vs non system scope threads Thread-Index: AcO3l9jqSQ61H2U/SEeUZ/pS/iRNgQFnhJ64 From: "Christopher M. Sedore" To: "David Xu" cc: deischen@freebsd.org cc: threads@freebsd.org Subject: RE: KSE system scope vs non system scope threads 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, 08 Dec 2003 02:59:40 -0000 Sorry for the long delay in responding. We upgraded to 5.2Beta before = we did this trial, and after installing on our SMP machines (that's all = we've been using for tests), we haven't been able to get them stable--we = see panics within 15 minutes of boot once our threaded process begins. = To continue testing, we rebuilt the kernel uniproc. The change back to = v1.18 of thr_spinlock improves the situation but we're still seeing some = degradation, but it is shorter and shallower now than it was. I need to = do more thorough testing before I can claim that it is related to a KSE = issue--it could be some other performance oddity. =20 (I'm not approaching any of the kernel limits. I'm peaking around 30-40 = threads.) =20 As a side-note, could anyone offer any ideas as to why I'm getting an = error EAGAIN from sendfile when not using non-blocking sockets? As far = as I could determine, the only case where I should see EAGAIN is a NB = socket. I'm seeing this happen part way through a send (200k into a = 500k send in one instance). I'm expecting to have to set up a kernel = debugger to trace it out since a scan of the kernel source doesn't show = any simple reason why this might happen. =20 -Chris ________________________________ From: David Xu [mailto:davidxu@freebsd.org] Sent: Sun 11/30/2003 6:25 PM To: Christopher M. Sedore Cc: deischen@freebsd.org; threads@freebsd.org Subject: Re: KSE system scope vs non system scope threads Christopher M. Sedore wrote: >I'm using blocking connects. Degradation is I should be moving = ~5-7MB/sec (and I do if I don't try to connect to any hosts that are = down). Once I do, I see fluctuations from ~15-20KB/sec (note: KB) to = 3-5MB/sec, somewhat associated with when the connects happen. Running = libthr, I move 6-7MB/sec consistently (until everything hangs up showing = sigwait as the status in top, anyway). System scope threads turn in = numbers from 5-6MB/sec. (Note I don't have any hang problems under KSE, = only libthr.) > >On Monday I'm going to try David Xu's suggestion of trying v1.18 of = thr_spinlock.c to see if that helps. > >=20 > I don't know if you hit a hard limit in kernel. The hard limit is sysctl kern.threads.max_threads_per_proc, default is 150, it means system only allows 150 threads to be blocked in kernel, if you hit the limits, then performance will be degraded. David Xu >-Chris >_______________________________________________ >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" > >=20 > From owner-freebsd-threads@FreeBSD.ORG Sun Dec 7 19:12:17 2003 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 B93C216A4CE for ; Sun, 7 Dec 2003 19:12:17 -0800 (PST) Received: from qwerty.maxwell.syr.edu (qwerty.maxwell.syr.edu [128.230.129.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F91643FCB for ; Sun, 7 Dec 2003 19:12:14 -0800 (PST) (envelope-from cmsedore@maxwell.syr.edu) Received: from qwerty.maxwell.syr.edu (qwerty.maxwell.syr.edu [128.230.129.248])hB83CDb1017729; Sun, 7 Dec 2003 22:12:13 -0500 (EST) (envelope-from cmsedore@maxwell.syr.edu) Date: Sun, 7 Dec 2003 22:12:13 -0500 (EST) From: Christopher Sedore To: Daniel Eischen In-Reply-To: Message-ID: <20031207220608.P17628-100000@qwerty.maxwell.syr.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: RE: KSE system scope vs non system scope threads 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, 08 Dec 2003 03:12:17 -0000 On Sun, 30 Nov 2003, Daniel Eischen wrote: > On Sun, 30 Nov 2003, Christopher M. Sedore wrote: > > [...] > > > > I'm using blocking connects. Degradation is I should be moving ~5-7MB/sec > > (and I do if I don't try to connect to any hosts that are down). Once I do, > > I see fluctuations from ~15-20KB/sec (note: KB) to 3-5MB/sec, somewhat > > associated with when the connects happen. Running libthr, I move 6-7MB/sec > > consistently (until everything hangs up showing sigwait as the status in > > top, anyway). System scope threads turn in numbers from 5-6MB/sec. (Note I > > don't have any hang problems under KSE, only libthr.) > > > > On Monday I'm going to try David Xu's suggestion of trying v1.18 of > > thr_spinlock.c to see if that helps. > > You should configure your mailer to wrap lines on outgoing mail... Sorry. This should be better. > > Are you using cancellation at all? I just noticed that libkse doesn't > seem to have a cancellation point for connect(). No cancellation. > Are you doing anything in signal handlers that you shouldn't be > doing? I only use them to catch sigterm, so this shouldn't be an issue. > Other than that, it sounds like a locking problem in the kernel. > A thread blocked in connect() in the kernel shouldn't prevent > upcalls allowing other threads to run. It sounds like the upcalls > aren't happening... v1.18 of the thr_spinlock.c seemed to help. I'm going to try to do more testing this week. As I noted in my other message, 5.2Beta won't run this code on SMP machines (all my code is userland code, too), so it took a while to actually get set up to try it out. Now I need to set up kernel debugging to see what's going on. Of course, 5.2Beta won't run under VMWare either...sigh. -Chris From owner-freebsd-threads@FreeBSD.ORG Sun Dec 7 19:55:00 2003 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 4ECDF16A4CE; Sun, 7 Dec 2003 19:55:00 -0800 (PST) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6DBC43FCB; Sun, 7 Dec 2003 19:54:50 -0800 (PST) (envelope-from davidxu@viatech.com.cn) Received: from viatech.com.cn (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XY9LRDTL; Mon, 8 Dec 2003 11:33:28 +0800 Message-ID: <3FD3F773.9060500@viatech.com.cn> Date: Mon, 08 Dec 2003 12:00:51 +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: "Christopher M. Sedore" References: <32A8B2CB12BFC84D8D11D872C787AA9A02B1F7D9@EXCHANGE.forest.maxwell.syr.edu> In-Reply-To: <32A8B2CB12BFC84D8D11D872C787AA9A02B1F7D9@EXCHANGE.forest.maxwell.syr.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: deischen@freebsd.org cc: threads@freebsd.org cc: David Xu Subject: Re: KSE system scope vs non system scope threads 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, 08 Dec 2003 03:55:00 -0000 Christopher M. Sedore wrote: >Sorry for the long delay in responding. We upgraded to 5.2Beta before we did this trial, and after installing on our SMP machines (that's all we've been using for tests), we haven't been able to get them stable--we see panics within 15 minutes of boot once our threaded process begins. To continue testing, we rebuilt the kernel uniproc. The change back to v1.18 of thr_spinlock improves the situation but we're still seeing some degradation, but it is shorter and shallower now than it was. I need to do more thorough testing before I can claim that it is related to a KSE issue--it could be some other performance oddity. > Are there some signals should be processed while doing transfering or connecting, I think spinlock revision 1.18 is still not perfect, it uses low level thread lock, and still prevents signals be processed by threads, probably we should use mutex. > >(I'm not approaching any of the kernel limits. I'm peaking around 30-40 threads.) > >As a side-note, could anyone offer any ideas as to why I'm getting an error EAGAIN from sendfile when not using non-blocking sockets? As far as I could determine, the only case where I should see EAGAIN is a NB socket. I'm seeing this happen part way through a send (200k into a 500k send in one instance). I'm expecting to have to set up a kernel debugger to trace it out since a scan of the kernel source doesn't show any simple reason why this might happen. > > I don't have any idea. > >-Chris > > David Xu From owner-freebsd-threads@FreeBSD.ORG Mon Dec 8 08:21:44 2003 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 59C2B16A4CE for ; Mon, 8 Dec 2003 08:21:44 -0800 (PST) Received: from bbnest.net (m208023.ap.plala.or.jp [219.164.208.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C7A43F85 for ; Mon, 8 Dec 2003 08:21:42 -0800 (PST) (envelope-from bland@FreeBSD.org) Received: from FreeBSD.org (bland@localhost [127.0.0.1]) by bbnest.net (8.12.10/8.12.10) with ESMTP id hB8Folj2054681 for ; Tue, 9 Dec 2003 00:50:47 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <3FD49DD7.60409@FreeBSD.org> Date: Tue, 09 Dec 2003 00:50:47 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: threads@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Minor pthrerad_mutex_unlock() issue 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, 08 Dec 2003 16:21:44 -0000 Guys, During recent bug hunting in ports I found wired (or better to say as I think incorrect) behaviour of mutex unlocking code. Final unlock in code snippet given bellow will fail with EINVAL. There is special '?' switch in thr_mutex.c:mutex_lock_common() wich proceses mutexes with 0 initialized m_owner field this way. Normally it should rerturn EPERM I guess. It was confusing to see EINVAL return from pthread_cond_wait() as a side effect of this. I was looking for some memory corruption instead of realizing that simply there is no prior mutex locking took place :-( #include #include int main() { pthread_mutex_t m; pthread_mutex_init(&m, NULL); printf("%d", pthread_mutex_unlock(&m)); return 0; } I propose to remove special procesing for m_owner == NULL. Simple != curthread will be enough to report EPERM. All the best, Alexander. ps. Btw, pthread_cond_*() man pages need to be updated to indicate that there is EPERM return code possible. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 8 11:05:42 2003 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 313F816A4CF for ; Mon, 8 Dec 2003 11:05:42 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D50FA4405C for ; Mon, 8 Dec 2003 11:01:51 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hB8J1oFY057064 for ; Mon, 8 Dec 2003 11:01:51 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hB8J1neu057053 for freebsd-threads@freebsd.org; Mon, 8 Dec 2003 11:01:49 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 8 Dec 2003 11:01:49 -0800 (PST) Message-Id: <200312081901.hB8J1neu057053@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, 08 Dec 2003 19:05:42 -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 o [2002/01/16] kern/33951 threads pthread_cancel is ignored 2 problems 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/04/02] bin/26307 threads libc_r aborts when using the KDE media pl o [2001/10/31] bin/31661 threads pthread_kill signal handler doesn't get s o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/03/07] bin/35622 threads sigaltstack is missing in libc_r 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 [2002/10/10] kern/43887 threads abnormal CPU useage when use pthread_mute 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 o [2003/05/30] kern/52817 threads top(1) shows garbage for threaded process 19 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 o [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Dec 8 17:45:46 2003 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 9E06316A4CE for ; Mon, 8 Dec 2003 17:45:46 -0800 (PST) Received: from smtp1.jp.viruscheck.net (smtp1.jp.viruscheck.net [154.33.69.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1643243D2D for ; Mon, 8 Dec 2003 17:45:43 -0800 (PST) (envelope-from bland@freebsd.org) Received: from scan2.jp.viruscheck.net ([154.33.69.37] helo=mail3.jp.viruscheck.net) by smtp1.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1ATWwY-0001ph-00 for threads@freebsd.org; Tue, 09 Dec 2003 10:45:42 +0900 Received: from [220.220.111.152] (helo=noc.orchid) by mail3.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1ATWwX-0000LK-00 for threads@FreeBSD.org; Tue, 09 Dec 2003 10:45:41 +0900 Received: from FreeBSD.org (horse.orchid [89.60.10.11]) by noc.orchid (8.12.9p2/8.12.9) with ESMTP id hB91je4v014733 for ; Tue, 9 Dec 2003 10:45:40 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <3FD52944.40007@FreeBSD.org> Date: Tue, 09 Dec 2003 10:45:40 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: threads@FreeBSD.org Content-Type: multipart/mixed; boundary="------------060707010505080100050504" Subject: typo in my last post 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, 09 Dec 2003 01:45:46 -0000 This is a multi-part message in MIME format. --------------060707010505080100050504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please read thr_mutex.c:mutex_lock_common() as thr_mutex.c:mutex_unlock_common(). I also think it will be good to add this: http://www.opengroup.org/onlinepubs/007904975/functions/pthread_mutex_lock.html Here is a quote: ERRORS ... [EPERM] The current thread does not own the mutex. ... Wich is similar to our: ... [EPERM] The current thread does not hold a lock on mutex. ... And this is what actually happen when mutex just intialized or unlocked. It's vaild but simply owned by no one therefore not by current thread. What I trying to say that current behaviour looks like: ... [EPERM] Mutex hold by another thread. ... See also proposed patch attached. Thanks, Alexander. --------------060707010505080100050504 Content-Type: text/plain; name="libpthread.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libpthread.patch" cvs server: Diffing . Index: thr_mutex.c =================================================================== RCS file: /home/ncvs/src/lib/libpthread/thread/thr_mutex.c,v retrieving revision 1.44 diff -u -r1.44 thr_mutex.c --- thr_mutex.c 9 Dec 2003 00:52:28 -0000 1.44 +++ thr_mutex.c 9 Dec 2003 01:40:21 -0000 @@ -1001,11 +1001,8 @@ * mutex: */ if ((*m)->m_owner != curthread) - /* - * Return an invalid argument error for no - * owner and a permission error otherwise: - */ - ret = (*m)->m_owner == NULL ? EINVAL : EPERM; + /* We're not own this one */ + ret = EPERM; else if (((*m)->m_type == PTHREAD_MUTEX_RECURSIVE) && ((*m)->m_count > 0)) @@ -1039,11 +1036,8 @@ * mutex: */ if ((*m)->m_owner != curthread) - /* - * Return an invalid argument error for no - * owner and a permission error otherwise: - */ - ret = (*m)->m_owner == NULL ? EINVAL : EPERM; + /* We're not own this one */ + ret = EPERM; else if (((*m)->m_type == PTHREAD_MUTEX_RECURSIVE) && ((*m)->m_count > 0)) @@ -1096,11 +1090,8 @@ * mutex: */ if ((*m)->m_owner != curthread) - /* - * Return an invalid argument error for no - * owner and a permission error otherwise: - */ - ret = (*m)->m_owner == NULL ? EINVAL : EPERM; + /* We're not own this one */ + ret = EPERM; else if (((*m)->m_type == PTHREAD_MUTEX_RECURSIVE) && ((*m)->m_count > 0)) --------------060707010505080100050504-- From owner-freebsd-threads@FreeBSD.ORG Fri Dec 12 15:52:14 2003 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 6902416A4CE for ; Fri, 12 Dec 2003 15:52:14 -0800 (PST) Received: from qwerty.maxwell.syr.edu (qwerty.maxwell.syr.edu [128.230.129.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8682543D2D for ; Fri, 12 Dec 2003 15:52:11 -0800 (PST) (envelope-from cmsedore@maxwell.syr.edu) Received: from qwerty.maxwell.syr.edu (qwerty.maxwell.syr.edu [128.230.129.248])hBCNqAb1047377; Fri, 12 Dec 2003 18:52:10 -0500 (EST) (envelope-from cmsedore@maxwell.syr.edu) Date: Fri, 12 Dec 2003 18:52:10 -0500 (EST) From: Christopher Sedore To: Daniel Eischen In-Reply-To: Message-ID: <20031212184457.S47162-100000@qwerty.maxwell.syr.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: RE: KSE system scope vs non system scope threads 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: Fri, 12 Dec 2003 23:52:14 -0000 On Mon, 8 Dec 2003, Daniel Eischen wrote: > On Sun, 7 Dec 2003, Christopher Sedore wrote: > > > > On Sun, 30 Nov 2003, Daniel Eischen wrote: > > > > > On Sun, 30 Nov 2003, Christopher M. Sedore wrote: > > > > > > [...] > > > > v1.18 of the thr_spinlock.c seemed to help. I'm going to try to do more > > testing this week. As I noted in my other message, 5.2Beta won't run this > > code on SMP machines (all my code is userland code, too), so it took a > > while to actually get set up to try it out. Now I need to set up kernel > > debugging to see what's going on. > > Are you using gethostby* or anything else in libc that isn't > thread-safe without using mutexes to protect them? I had a couple stray uses of strtok left over from an earlier non-threaded version--I cleaned them up, but that didn't help. Whatever it was, it was fixed in between 5.2Beta and 5.2RC1. I'm not having any performance problems with system scope threads at all, and SMP works. Overall performance is dramatically better than it had been previously. I'll try process-scope kse threads again soon. I'm just happy I don't need to move to a different platform. Now, I just have to track down why I'm getting EAGAIN from sendfile() when I'm not using non-blocking sockets... -Chris From owner-freebsd-threads@FreeBSD.ORG Fri Dec 12 23:18:55 2003 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 E057516A4CE for ; Fri, 12 Dec 2003 23:18:55 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA9243D1F for ; Fri, 12 Dec 2003 23:18:54 -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 hBD7Isml001000; Sat, 13 Dec 2003 02:18:54 -0500 (EST) Date: Sat, 13 Dec 2003 02:18:53 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Christopher Sedore In-Reply-To: <20031212184457.S47162-100000@qwerty.maxwell.syr.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: RE: KSE system scope vs non system scope threads 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: Sat, 13 Dec 2003 07:18:56 -0000 On Fri, 12 Dec 2003, Christopher Sedore wrote: > > On Mon, 8 Dec 2003, Daniel Eischen wrote: > > > > > Are you using gethostby* or anything else in libc that isn't > > thread-safe without using mutexes to protect them? > > I had a couple stray uses of strtok left over from an earlier non-threaded > version--I cleaned them up, but that didn't help. Whatever it was, it was > fixed in between 5.2Beta and 5.2RC1. I'm not having any performance > problems with system scope threads at all, and SMP works. Overall > performance is dramatically better than it had been previously. I'll try > process-scope kse threads again soon. I'm just happy I don't need to move > to a different platform. > > Now, I just have to track down why I'm getting EAGAIN from sendfile() > when I'm not using non-blocking sockets... Yes, well, try digging in the kernel for that. Neither libthr or libkse do anything WRT sendfile(), while libc_r needs a wrapper for it. -- Dan