From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 05:39:52 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 0F3DA37B407; Sun, 6 Apr 2003 05:39:51 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B71CC43FDD; Sun, 6 Apr 2003 05:39:50 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h36CdoBg003163; Sun, 6 Apr 2003 08:39:50 -0400 (EDT) Received: from localhost (eischen@localhost)h36CdnQG003160; Sun, 6 Apr 2003 08:39:49 -0400 (EDT) Date: Sun, 6 Apr 2003 08:39:49 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <000d01c2fc0d$6d404c60$0701a8c0@tiger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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: Sun, 06 Apr 2003 12:39:52 -0000 On Sun, 6 Apr 2003, David Xu wrote: > > ----- Original Message ----- > From: "Daniel Eischen" > To: "DavidXu" > Cc: > Sent: Sunday, April 06, 2003 2:40 PM > Subject: Re: PS_BLOCKED > > > > On Sun, 6 Apr 2003, DavidXu wrote: > > > > > Daniel, > > > > > > I saw your code in thr_kern.c assumes that a blocked thread > > > in kernel will always be returned in same upcall(your userland > > > kse)? However, current kernel will returned this context in one > > > of upcall in the same ksegrp, so there is race in your code, > > > I think this may be a kernel bug but not yours, this does not > > > very respects original paper. > > > > Hey, glad to see you got through to an @freebsd.org list > > from home (I presume)! > > > > Actually, I got rid of PS_BLOCKED earlier today. I think > > I deal with blocked threads OK now and I don't think I > > assume (any longer) that they belong to any particular > > KSE. > > > > I've made some decent progress and can run the mutex test > > sucessfully, and can run most of the ACE tests also. Some > > of the ACE tests fail, but some also fail with libc_r > > (I don't think it's the threads library). I'm running > > them with libc_r now and will compare against libkse. > > > Congratulation! I know ACE is a big monster, it is a very practical > test suit. Yes, it's helped me find a lot of bugs in libc_r :-) > > I've still got one bug I am trying to hunt down with > > signals -- the sigwait test fails. Process (kill) signals > > don't seem to wakeup threads in sigwait(). I'm not sure > > if it is a kernel bug or not, but I suspect it's > > something I'm doing. > > > > I don't know if Jeff's signal change in kernel affects your code, > but signals lost problem is still not fixed, a thread exports its > context and exits would lost signals dispatched to it, even the > signals is not for the thread, but for process. I'll do some more debugging today and see if it is in the UTS or the kernel. > > One question. What happens when kse_release(tsp) is > > called when k_mbx.km_curthread == NULL? Does it > > just return after the timeout, or is there a new > > upcall? > > A new upcall will be scheduled, does not return. Is there a way that we could get it to just return? I would like to make PTHREAD_SCOPE_SYSTEM threads (one thread per KSE/KSEG) work without a separate scheduler stack. We should be able to do everything from the thread's stack. I'd be willing to add a flag or something to the KSE mailbox to get this behaviour. > > And if kse_A->k_mbx.km_curthread == NULL > > and it is in a kse_release(tsp), can another kse > > interrupt it (before the timeout) with kse_wakeup()? > > > Yes, you can use kse_wakeup to interrupt it, pass the > kse mailbox address to the syscall. Cool, that's what I thought. I forgot to mention it, but I think I found a kernel bug also. Sometimes when the kernel exports a context to the UTS the %gs register isn't set; it doesn't seem to be saved in some instances. I think it might only be when a kernel thread is swapped out (without blocking). Does %gs always get saved, even if the thread is interrupted by an interrupt? > > -- > > Dan Eischen > > > > > > Let's Go Orange! > > Would there be a new patch against code in the src tree > I can download ? Done. I'll try to do some more debugging and update it again later today. http://people.freebsd.org/~deischen/libpthread.diffs -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 08:05:28 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 8D58937B404; Sun, 6 Apr 2003 08:05:28 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F38E43FDD; Sun, 6 Apr 2003 08:05:27 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h36F5QBg019030; Sun, 6 Apr 2003 11:05:26 -0400 (EDT) Received: from localhost (eischen@localhost)h36F5Pd5019027; Sun, 6 Apr 2003 11:05:26 -0400 (EDT) Date: Sun, 6 Apr 2003 11:05:25 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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: Sun, 06 Apr 2003 15:05:28 -0000 On Sun, 6 Apr 2003, Daniel Eischen wrote: > On Sun, 6 Apr 2003, David Xu wrote: > > > > ----- Original Message ----- > > From: "Daniel Eischen" > > To: "DavidXu" > > Cc: > > Sent: Sunday, April 06, 2003 2:40 PM > > Subject: Re: PS_BLOCKED > > > > > I've still got one bug I am trying to hunt down with > > > signals -- the sigwait test fails. Process (kill) signals > > > don't seem to wakeup threads in sigwait(). I'm not sure > > > if it is a kernel bug or not, but I suspect it's > > > something I'm doing. > > > > > > > I don't know if Jeff's signal change in kernel affects your code, > > but signals lost problem is still not fixed, a thread exports its > > context and exits would lost signals dispatched to it, even the > > signals is not for the thread, but for process. > > I'll do some more debugging today and see if it is in the > UTS or the kernel. I think there is a problem in the kernel; probably Jeff's changes that broke it. When the UTS gets a signal (in k_mbx.km_sigscaught), the signal mask in the kernel is never cleared. The UTS only ever gets one signal. If I use __sys_sigprocmask() to clear the kernel signal mask after the UTS receives the signal(s), then everything works and the sigwait test passes. I'm not sure what we should do. The UTS is currently installing signal handlers with all signals masked (act.sa_mask). We could clear this mask and perhaps solve the problem that way. But when there are multiple (kernel) threads each with its own mask and Jeff's recent changes, there are other problems I think. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 18:14:33 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 8A4DD37B401 for ; Sun, 6 Apr 2003 18:14:33 -0700 (PDT) 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 3CAB443FA3 for ; Sun, 6 Apr 2003 18:14:29 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQP2PS; Mon, 7 Apr 2003 09:00:58 +0800 Message-ID: <003501c2fca3$3e20c900$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Mon, 7 Apr 2003 09:15:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 07 Apr 2003 01:14:33 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Sunday, April 06, 2003 8:39 PM Subject: Re: PS_BLOCKED > On Sun, 6 Apr 2003, David Xu wrote: > >=20 > > ----- Original Message -----=20 > > From: "Daniel Eischen" > > To: "DavidXu" > > Cc: > > Sent: Sunday, April 06, 2003 2:40 PM > > Subject: Re: PS_BLOCKED > > ... > > > I've still got one bug I am trying to hunt down with > > > signals -- the sigwait test fails. Process (kill) signals > > > don't seem to wakeup threads in sigwait(). I'm not sure > > > if it is a kernel bug or not, but I suspect it's > > > something I'm doing. > > >=20 > >=20 > > I don't know if Jeff's signal change in kernel affects your code, > > but signals lost problem is still not fixed, a thread exports its > > context and exits would lost signals dispatched to it, even the > > signals is not for the thread, but for process. >=20 > I'll do some more debugging today and see if it is in the > UTS or the kernel. >=20 Note that Jeff's change to signal code in kernel also broke our kse_release code, because the upcall thread is waiting for signal in kse_release too, but now it is possible the upcall thread won't receive any signal, signal is delivered to a non-upcall thread and lost. > > > One question. What happens when kse_release(tsp) is > > > called when k_mbx.km_curthread =3D=3D NULL? Does it > > > just return after the timeout, or is there a new > > > upcall? > >=20 > > A new upcall will be scheduled, does not return. >=20 > Is there a way that we could get it to just return? I would > like to make PTHREAD_SCOPE_SYSTEM threads (one thread per > KSE/KSEG) work without a separate scheduler stack. We > should be able to do everything from the thread's stack. > I'd be willing to add a flag or something to the KSE > mailbox to get this behaviour. >=20 It can be done by add a flags to kse_mailbox.km_flags to tell kernel to not schedule an upcall. > > > And if kse_A->k_mbx.km_curthread =3D=3D NULL > > > and it is in a kse_release(tsp), can another kse > > > interrupt it (before the timeout) with kse_wakeup()? > > >=20 > > Yes, you can use kse_wakeup to interrupt it, pass the > > kse mailbox address to the syscall. >=20 > Cool, that's what I thought. >=20 > I forgot to mention it, but I think I found a kernel bug also. > Sometimes when the kernel exports a context to the UTS the > %gs register isn't set; it doesn't seem to be saved in some > instances. I think it might only be when a kernel thread > is swapped out (without blocking). Does %gs always get saved, > even if the thread is interrupted by an interrupt? >=20 Yes, I will fix it and give you a patch. > > > --=20 > > > Dan Eischen > > >=20 > > >=20 > > > Let's Go Orange! > >=20 > > Would there be a new patch against code in the src tree=20 > > I can download ? >=20 > Done. I'll try to do some more debugging and update it again > later today. >=20 > http://people.freebsd.org/~deischen/libpthread.diffs >=20 Got it! > --=20 > Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 18:16: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 42F7D37B401 for ; Sun, 6 Apr 2003 18:16:55 -0700 (PDT) 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 2D4C843F3F for ; Sun, 6 Apr 2003 18:16:53 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQP2PZ; Mon, 7 Apr 2003 09:03:24 +0800 Message-ID: <003b01c2fca3$95050c40$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Mon, 7 Apr 2003 09:18:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 07 Apr 2003 01:16:55 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Sunday, April 06, 2003 11:05 PM Subject: Re: PS_BLOCKED > On Sun, 6 Apr 2003, Daniel Eischen wrote: >=20 > > On Sun, 6 Apr 2003, David Xu wrote: > > >=20 > > > ----- Original Message -----=20 > > > From: "Daniel Eischen" > > > To: "DavidXu" > > > Cc: > > > Sent: Sunday, April 06, 2003 2:40 PM > > > Subject: Re: PS_BLOCKED > > > > > > > I've still got one bug I am trying to hunt down with > > > > signals -- the sigwait test fails. Process (kill) signals > > > > don't seem to wakeup threads in sigwait(). I'm not sure > > > > if it is a kernel bug or not, but I suspect it's > > > > something I'm doing. > > > >=20 > > >=20 > > > I don't know if Jeff's signal change in kernel affects your code, > > > but signals lost problem is still not fixed, a thread exports its > > > context and exits would lost signals dispatched to it, even the > > > signals is not for the thread, but for process. > >=20 > > I'll do some more debugging today and see if it is in the > > UTS or the kernel. >=20 > I think there is a problem in the kernel; probably Jeff's changes > that broke it. >=20 > When the UTS gets a signal (in k_mbx.km_sigscaught), the signal > mask in the kernel is never cleared. The UTS only ever gets > one signal. If I use __sys_sigprocmask() to clear the kernel > signal mask after the UTS receives the signal(s), then everything > works and the sigwait test passes. >=20 > I'm not sure what we should do. The UTS is currently installing > signal handlers with all signals masked (act.sa_mask). We could > clear this mask and perhaps solve the problem that way. But when > there are multiple (kernel) threads each with its own mask and > Jeff's recent changes, there are other problems I think. >=20 See my previous mail, I said current KSE signal code was totally broken by jeff's signal change.=20 > --=20 > Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 18:29:58 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 002C337B401 for ; Sun, 6 Apr 2003 18:29:57 -0700 (PDT) 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 42D1343FCB for ; Sun, 6 Apr 2003 18:29:55 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQP2RC; Mon, 7 Apr 2003 09:16:24 +0800 Message-ID: <006d01c2fca5$663c33a0$f001a8c0@davidw2k> From: "David Xu" To: Date: Mon, 7 Apr 2003 09:31:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: freebsd-threads@freebsd.org 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, 07 Apr 2003 01:29:58 -0000 I can not get a copy of every message I posted to the list, why? I had already turned on "Receive your own posts to the list? " option. David Xu From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 20:17:22 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 824B737B401; Sun, 6 Apr 2003 20:17:22 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB6BC43F93; Sun, 6 Apr 2003 20:17:21 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <20030407031720002004nv4ke>; Mon, 7 Apr 2003 03:17:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA57001; Sun, 6 Apr 2003 20:17:19 -0700 (PDT) Date: Sun, 6 Apr 2003 20:17:17 -0700 (PDT) From: Julian Elischer To: David Xu In-Reply-To: <003501c2fca3$3e20c900$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 07 Apr 2003 03:17:22 -0000 On Mon, 7 Apr 2003, David Xu wrote: > > ----- Original Message ----- > From: "Daniel Eischen" > To: "David Xu" > Cc: > Sent: Sunday, April 06, 2003 8:39 PM > Subject: Re: PS_BLOCKED > > > > On Sun, 6 Apr 2003, David Xu wrote: > > > > > > ----- Original Message ----- > > > From: "Daniel Eischen" > > > To: "DavidXu" > > > Cc: > > > Sent: Sunday, April 06, 2003 2:40 PM > > > Subject: Re: PS_BLOCKED > > > ... > > > > I'll do some more debugging today and see if it is in the > > UTS or the kernel. > > > > Note that Jeff's change to signal code in kernel also broke > our kse_release code, because the upcall thread is waiting for > signal in kse_release too, but now it is possible the upcall > thread won't receive any signal, signal is delivered to a > non-upcall thread and lost. > > > > > One question. What happens when kse_release(tsp) is > > > > called when k_mbx.km_curthread == NULL? Does it > > > > just return after the timeout, or is there a new > > > > upcall? > > > > > > A new upcall will be scheduled, does not return. > > > > Is there a way that we could get it to just return? I would > > like to make PTHREAD_SCOPE_SYSTEM threads (one thread per > > KSE/KSEG) work without a separate scheduler stack. We > > should be able to do everything from the thread's stack. > > I'd be willing to add a flag or something to the KSE > > mailbox to get this behaviour. > > > > It can be done by add a flags to kse_mailbox.km_flags to > tell kernel to not schedule an upcall. If you have this behaviour, please make it an option. Possibly One way to do this would be to call kse_create, with the 'new-ksegrp' flag set but the mailbox pointer set to NULL. However why do you want to use kse_release for this. If you have only one thread in the KSEGRP then I'd call this "usleep()". I think kse_release should be left alone. It should never return. > > > > > And if kse_A->k_mbx.km_curthread == NULL > > > > and it is in a kse_release(tsp), can another kse > > > > interrupt it (before the timeout) with kse_wakeup()? > > > > > > > Yes, you can use kse_wakeup to interrupt it, pass the > > > kse mailbox address to the syscall. > > > > Cool, that's what I thought. > > > > I forgot to mention it, but I think I found a kernel bug also. > > Sometimes when the kernel exports a context to the UTS the > > %gs register isn't set; it doesn't seem to be saved in some > > instances. I think it might only be when a kernel thread > > is swapped out (without blocking). Does %gs always get saved, > > even if the thread is interrupted by an interrupt? > > > > Yes, I will fix it and give you a patch. > > > > > -- > > > > Dan Eischen > > > > > > > > > > > > Let's Go Orange! > > > > > > Would there be a new patch against code in the src tree > > > I can download ? > > > > Done. I'll try to do some more debugging and update it again > > later today. > > > > http://people.freebsd.org/~deischen/libpthread.diffs > > > > Got it! > > > -- > > Dan Eischen > > _______________________________________________ > 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 Sun Apr 6 20:22:29 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 7289937B401; Sun, 6 Apr 2003 20:22:29 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D0B043FAF; Sun, 6 Apr 2003 20:22:28 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <20030407032227002004lsgpe>; Mon, 7 Apr 2003 03:22:27 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA57040; Sun, 6 Apr 2003 20:22:25 -0700 (PDT) Date: Sun, 6 Apr 2003 20:22:24 -0700 (PDT) From: Julian Elischer To: David Xu In-Reply-To: <003b01c2fca3$95050c40$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: core@freebsd.org cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: KSE signals broken by 1:1 commit. 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, 07 Apr 2003 03:22:29 -0000 I'm going to apply to core since jeff is absent, to have permission for us to fix it and possibly break 1:1 (*). I specifically asked him to ensure that this didn't happen if he committed his changes and told him it looked as if it would. (*) I don't WANT to break 1:1 but we can't test it at the moment as it core-dumps so we have no way to see if we are breaking it :-( On Mon, 7 Apr 2003, David Xu wrote: > > ----- Original Message ----- > From: "Daniel Eischen" > To: "David Xu" > Cc: > Sent: Sunday, April 06, 2003 11:05 PM > Subject: Re: PS_BLOCKED > > > > On Sun, 6 Apr 2003, Daniel Eischen wrote: > > > > > On Sun, 6 Apr 2003, David Xu wrote: > > > > > > > > ----- Original Message ----- > > > > From: "Daniel Eischen" > > > > To: "DavidXu" > > > > Cc: > > > > Sent: Sunday, April 06, 2003 2:40 PM > > > > Subject: Re: PS_BLOCKED > > > > > > > > > I've still got one bug I am trying to hunt down with > > > > > signals -- the sigwait test fails. Process (kill) signals > > > > > don't seem to wakeup threads in sigwait(). I'm not sure > > > > > if it is a kernel bug or not, but I suspect it's > > > > > something I'm doing. > > > > > > > > > > > > > I don't know if Jeff's signal change in kernel affects your code, > > > > but signals lost problem is still not fixed, a thread exports its > > > > context and exits would lost signals dispatched to it, even the > > > > signals is not for the thread, but for process. > > > > > > I'll do some more debugging today and see if it is in the > > > UTS or the kernel. > > > > I think there is a problem in the kernel; probably Jeff's changes > > that broke it. > > > > When the UTS gets a signal (in k_mbx.km_sigscaught), the signal > > mask in the kernel is never cleared. The UTS only ever gets > > one signal. If I use __sys_sigprocmask() to clear the kernel > > signal mask after the UTS receives the signal(s), then everything > > works and the sigwait test passes. > > > > I'm not sure what we should do. The UTS is currently installing > > signal handlers with all signals masked (act.sa_mask). We could > > clear this mask and perhaps solve the problem that way. But when > > there are multiple (kernel) threads each with its own mask and > > Jeff's recent changes, there are other problems I think. > > > > See my previous mail, I said current KSE signal code was totally broken > by jeff's signal change. > > > -- > > Dan Eischen > > > _______________________________________________ > 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 Sun Apr 6 20:36: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 D520737B401; Sun, 6 Apr 2003 20:36:46 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0059743F75; Sun, 6 Apr 2003 20:36:46 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h373ajBg016261; Sun, 6 Apr 2003 23:36:45 -0400 (EDT) Received: from localhost (eischen@localhost)h373ai0U016258; Sun, 6 Apr 2003 23:36:44 -0400 (EDT) Date: Sun, 6 Apr 2003 23:36:44 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <003501c2fca3$3e20c900$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 07 Apr 2003 03:36:47 -0000 On Mon, 7 Apr 2003, David Xu wrote: > > ----- Original Message ----- > From: "Daniel Eischen" > To: "David Xu" > Cc: > Sent: Sunday, April 06, 2003 8:39 PM > Subject: Re: PS_BLOCKED > > > > On Sun, 6 Apr 2003, David Xu wrote: > > > > > > ----- Original Message ----- > > > From: "Daniel Eischen" > > > To: "DavidXu" > > > Cc: > > > Sent: Sunday, April 06, 2003 2:40 PM > > > Subject: Re: PS_BLOCKED > > > ... > > > > I've still got one bug I am trying to hunt down with > > > > signals -- the sigwait test fails. Process (kill) signals > > > > don't seem to wakeup threads in sigwait(). I'm not sure > > > > if it is a kernel bug or not, but I suspect it's > > > > something I'm doing. > > > > > > > > > > I don't know if Jeff's signal change in kernel affects your code, > > > but signals lost problem is still not fixed, a thread exports its > > > context and exits would lost signals dispatched to it, even the > > > signals is not for the thread, but for process. > > > > I'll do some more debugging today and see if it is in the > > UTS or the kernel. > > > > Note that Jeff's change to signal code in kernel also broke > our kse_release code, because the upcall thread is waiting for > signal in kse_release too, but now it is possible the upcall > thread won't receive any signal, signal is delivered to a > non-upcall thread and lost. Ok. We need to fix that somehow. > > > > One question. What happens when kse_release(tsp) is > > > > called when k_mbx.km_curthread == NULL? Does it > > > > just return after the timeout, or is there a new > > > > upcall? > > > > > > A new upcall will be scheduled, does not return. > > > > Is there a way that we could get it to just return? I would > > like to make PTHREAD_SCOPE_SYSTEM threads (one thread per > > KSE/KSEG) work without a separate scheduler stack. We > > should be able to do everything from the thread's stack. > > I'd be willing to add a flag or something to the KSE > > mailbox to get this behaviour. > > > > It can be done by add a flags to kse_mailbox.km_flags to > tell kernel to not schedule an upcall. That would be convenient. > > > > And if kse_A->k_mbx.km_curthread == NULL > > > > and it is in a kse_release(tsp), can another kse > > > > interrupt it (before the timeout) with kse_wakeup()? > > > > > > > Yes, you can use kse_wakeup to interrupt it, pass the > > > kse mailbox address to the syscall. > > > > Cool, that's what I thought. > > > > I forgot to mention it, but I think I found a kernel bug also. > > Sometimes when the kernel exports a context to the UTS the > > %gs register isn't set; it doesn't seem to be saved in some > > instances. I think it might only be when a kernel thread > > is swapped out (without blocking). Does %gs always get saved, > > even if the thread is interrupted by an interrupt? > > > > Yes, I will fix it and give you a patch. Thanks. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 20:45:57 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 68D2E37B401; Sun, 6 Apr 2003 20:45:57 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 706DF43F75; Sun, 6 Apr 2003 20:45:56 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h373jpBg017094; Sun, 6 Apr 2003 23:45:51 -0400 (EDT) Received: from localhost (eischen@localhost)h373jpEr017091; Sun, 6 Apr 2003 23:45:51 -0400 (EDT) Date: Sun, 6 Apr 2003 23:45:50 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 07 Apr 2003 03:45:57 -0000 On Sun, 6 Apr 2003, Julian Elischer wrote: > On Mon, 7 Apr 2003, David Xu wrote: > > > > > ----- Original Message ----- > > From: "Daniel Eischen" > > To: "David Xu" > > Cc: > > Sent: Sunday, April 06, 2003 8:39 PM > > Subject: Re: PS_BLOCKED > > > > > > > On Sun, 6 Apr 2003, David Xu wrote: > > > > > > > > ----- Original Message ----- > > > > From: "Daniel Eischen" > > > > To: "DavidXu" > > > > Cc: > > > > Sent: Sunday, April 06, 2003 2:40 PM > > > > Subject: Re: PS_BLOCKED > > > > ... > > > > > > I'll do some more debugging today and see if it is in the > > > UTS or the kernel. > > > > > > > Note that Jeff's change to signal code in kernel also broke > > our kse_release code, because the upcall thread is waiting for > > signal in kse_release too, but now it is possible the upcall > > thread won't receive any signal, signal is delivered to a > > non-upcall thread and lost. > > > > > > > One question. What happens when kse_release(tsp) is > > > > > called when k_mbx.km_curthread == NULL? Does it > > > > > just return after the timeout, or is there a new > > > > > upcall? > > > > > > > > A new upcall will be scheduled, does not return. > > > > > > Is there a way that we could get it to just return? I would > > > like to make PTHREAD_SCOPE_SYSTEM threads (one thread per > > > KSE/KSEG) work without a separate scheduler stack. We > > > should be able to do everything from the thread's stack. > > > I'd be willing to add a flag or something to the KSE > > > mailbox to get this behaviour. > > > > > > > It can be done by add a flags to kse_mailbox.km_flags to > > tell kernel to not schedule an upcall. > > If you have this behaviour, please make it an option. Possibly > One way to do this would be to call kse_create, with the > 'new-ksegrp' flag set but the mailbox pointer set to NULL. > > However why do you want to use kse_release for this. > If you have only one thread in the KSEGRP then I'd call this > "usleep()". It's so that the common code (called by both scope system threads and scope process threads) can be the same. I don't want to have to add checks all over the place to see if the KSE is bound to a thread or not. Also, nanosleep doesn't work well because you can't wake it up with a KSE mailbox (kse_wakeup), plus there's a race condition if you try and wake it up before it actually gets to the kernel to sleep. The kse_wakeup() call is latched, so if it gets to the kernel first, the next kse_release() will notice it. > I think kse_release should be left alone. > It should never return. Actually, I think it should obey all the rules that system calls do. If the mailbox pointer is NULL, it returns normally (after timing out or getting woken up); otherwise an upcall is scheduled. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 21:20:16 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 EA5F837B401; Sun, 6 Apr 2003 21:20:16 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE24343FAF; Sun, 6 Apr 2003 21:20:15 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h374K9A7088581; Sun, 6 Apr 2003 22:20:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 06 Apr 2003 22:17:33 -0600 (MDT) Message-Id: <20030406.221733.12213570.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: References: <003b01c2fca3$95050c40$f001a8c0@davidw2k> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-threads@FreeBSD.ORG cc: core@FreeBSD.ORG cc: davidxu@FreeBSD.ORG cc: eischen@pcnet1.pcnet.com Subject: Re: KSE signals broken by 1:1 commit. 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, 07 Apr 2003 04:20:17 -0000 Julian, thanks for your message to core, but despite the included text, it is unclear what you want to do. Do you want a blank check to break things, or do is there a specific fix that was referred to elsewhere in the thread that was absent from the quoted material. Warner From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 21:53:01 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 4DC5837B401; Sun, 6 Apr 2003 21:53:01 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4432A43FA3; Sun, 6 Apr 2003 21:53:00 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h374r0xS073434; Mon, 7 Apr 2003 00:53:01 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h374r07k073433; Mon, 7 Apr 2003 00:53:00 -0400 (EDT) Date: Mon, 7 Apr 2003 00:53:00 -0400 From: Jake Burkholder To: Julian Elischer Message-ID: <20030407045300.GB67830@locore.ca> References: <003b01c2fca3$95050c40$f001a8c0@davidw2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: freebsd-threads@freebsd.org cc: core@freebsd.org cc: David Xu cc: Daniel Eischen Subject: Re: KSE signals broken by 1:1 commit. 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, 07 Apr 2003 04:53:01 -0000 Apparently, On Sun, Apr 06, 2003 at 08:22:24PM -0700, Julian Elischer said words to the effect of; > I'm going to apply to core since jeff is absent, to have permission for > us to fix it and possibly break 1:1 (*). I specifically asked him to > ensure > that this didn't happen if he committed his changes and told him it > looked as if it would. > > (*) I don't WANT to break 1:1 but we can't test it at the moment as it > core-dumps so we have no way to see if we are breaking it :-( Are any of you running an up to date kernel from after the lazy switch changes? If you create a process with multiple threads you will get a kernel panic in cpu_throw when the first one exits because thread_exit and thr_exit both clear td_proc and cpu_throw uses td_proc now. A program like this provokes it: #include void *foo(void *); int main(void) { pthread_t thread; void *ret; if (pthread_create(&thread, NULL, foo, NULL) != 0) err(1, NULL); if (pthread_join(thread, &ret) != 0) err(1, NULL); return (0); } void * foo(void *v) { printf("foo\n"); return (NULL); } This patch will allow you to run libthr apps to ensure that you don't break them: Index: kern/kern_thr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_thr.c,v retrieving revision 1.3 diff -u -r1.3 kern_thr.c --- kern/kern_thr.c 2 Apr 2003 23:53:29 -0000 1.3 +++ kern/kern_thr.c 6 Apr 2003 23:46:49 -0000 @@ -101,7 +101,9 @@ PROC_UNLOCK(p); td->td_kse = NULL; td->td_state = TDS_INACTIVE; +#ifdef nolonger td->td_proc = NULL; +#endif td->td_ksegrp = NULL; td->td_last_kse = NULL; thread_stash(td); Index: kern/kern_thread.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v retrieving revision 1.112 diff -u -r1.112 kern_thread.c --- kern/kern_thread.c 2 Apr 2003 23:53:29 -0000 1.112 +++ kern/kern_thread.c 6 Apr 2003 23:38:59 -0000 @@ -1242,7 +1242,9 @@ PROC_UNLOCK(p); td->td_kse = NULL; td->td_state = TDS_INACTIVE; +#ifdef nolonger td->td_proc = NULL; +#endif td->td_ksegrp = NULL; td->td_last_kse = NULL; PCPU_SET(deadthread, td); I think this issue can wait 3 days until jeff gets back. Jake From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 22:16: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 ED8D737B401; Sun, 6 Apr 2003 22:16:14 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADBF143FA3; Sun, 6 Apr 2003 22:16:13 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h375Fnq46881; Mon, 7 Apr 2003 01:15:49 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 7 Apr 2003 01:15:49 -0400 (EDT) From: Jeff Roberson To: Jake Burkholder In-Reply-To: <20030407045300.GB67830@locore.ca> Message-ID: <20030407010642.E86645-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: Julian Elischer cc: core@freebsd.org cc: freebsd-threads@freebsd.org cc: David Xu Subject: Re: KSE signals broken by 1:1 commit. 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, 07 Apr 2003 05:16:15 -0000 On Mon, 7 Apr 2003, Jake Burkholder wrote: > Apparently, On Sun, Apr 06, 2003 at 08:22:24PM -0700, > Julian Elischer said words to the effect of; > > > I'm going to apply to core since jeff is absent, to have permission for > > us to fix it and possibly break 1:1 (*). I specifically asked him to > > ensure > > that this didn't happen if he committed his changes and told him it > > looked as if it would. > > > > (*) I don't WANT to break 1:1 but we can't test it at the moment as it > > core-dumps so we have no way to see if we are breaking it :-( > > Are any of you running an up to date kernel from after the lazy switch > changes? If you create a process with multiple threads you will get a > kernel panic in cpu_throw when the first one exits because thread_exit > and thr_exit both clear td_proc and cpu_throw uses td_proc now. A program > like this provokes it: [snip test code] > > This patch will allow you to run libthr apps to ensure that you don't > break them: [snip patch] > > I think this issue can wait 3 days until jeff gets back. > > Jake Thanks jake.. I suspect that it can wait as well. I had reports from a user that this didn't break kse but I didn't specifically test it myself. People are using thr now though so I'd hope we could avoid breaking it. KSE signals didn't work well enough at the time that I commited thr to be too concerned. It seemed as if more work was required to get it right anyway. Could you please tell me exactly what you want and let me implement it instead of backing out working code. If you just want a per process or kseg mask we can do that although I'm not sure if this is correct. Really julian, after all your complaints about people asking you to backout code that broke the build I'd think you'd be a little more reasonable. Cheers, Jeff From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 22:59:59 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 1373A37B401; Sun, 6 Apr 2003 22:59:58 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B111843F93; Sun, 6 Apr 2003 22:59:55 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc53.attbi.com (rwcrmhc53) with ESMTP id <20030407055954053002m75ne>; Mon, 7 Apr 2003 05:59:55 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA57983; Sun, 6 Apr 2003 22:59:53 -0700 (PDT) Date: Sun, 6 Apr 2003 22:59:51 -0700 (PDT) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 07 Apr 2003 05:59:59 -0000 On Sun, 6 Apr 2003, Daniel Eischen wrote: > On Sun, 6 Apr 2003, Julian Elischer wrote: > > On Mon, 7 Apr 2003, David Xu wrote: > > > > > > > > ----- Original Message ----- > > > From: "Daniel Eischen" > > > To: "David Xu" > > > Cc: > > > Sent: Sunday, April 06, 2003 8:39 PM > > > Subject: Re: PS_BLOCKED > > > > > > > > > > On Sun, 6 Apr 2003, David Xu wrote: > > > > > > > > > > ----- Original Message ----- > > > > > From: "Daniel Eischen" > > > > > To: "DavidXu" > > > > > Cc: > > > > > Sent: Sunday, April 06, 2003 2:40 PM > > > > > Subject: Re: PS_BLOCKED > > > > > ... > > > > > > > > I'll do some more debugging today and see if it is in the > > > > UTS or the kernel. > > > > > > > > > > Note that Jeff's change to signal code in kernel also broke > > > our kse_release code, because the upcall thread is waiting for > > > signal in kse_release too, but now it is possible the upcall > > > thread won't receive any signal, signal is delivered to a > > > non-upcall thread and lost. > > > > > > > > > One question. What happens when kse_release(tsp) is > > > > > > called when k_mbx.km_curthread == NULL? Does it > > > > > > just return after the timeout, or is there a new > > > > > > upcall? > > > > > > > > > > A new upcall will be scheduled, does not return. > > > > > > > > Is there a way that we could get it to just return? I would > > > > like to make PTHREAD_SCOPE_SYSTEM threads (one thread per > > > > KSE/KSEG) work without a separate scheduler stack. We > > > > should be able to do everything from the thread's stack. > > > > I'd be willing to add a flag or something to the KSE > > > > mailbox to get this behaviour. > > > > > > > > > > It can be done by add a flags to kse_mailbox.km_flags to > > > tell kernel to not schedule an upcall. > > > > If you have this behaviour, please make it an option. Possibly > > One way to do this would be to call kse_create, with the > > 'new-ksegrp' flag set but the mailbox pointer set to NULL. > > > > However why do you want to use kse_release for this. > > If you have only one thread in the KSEGRP then I'd call this > > "usleep()". > > It's so that the common code (called by both scope system > threads and scope process threads) can be the same. I don't > want to have to add checks all over the place to see if the > KSE is bound to a thread or not. Also, nanosleep doesn't > work well because you can't wake it up with a KSE mailbox > (kse_wakeup), plus there's a race condition if you try and > wake it up before it actually gets to the kernel to sleep. > The kse_wakeup() call is latched, so if it gets to the kernel > first, the next kse_release() will notice it. you cannot wake up a thread with no upcall mailbox using kse_wakeup because there is no thread mailbox address to match. > > > I think kse_release should be left alone. > > It should never return. > > Actually, I think it should obey all the rules that system > calls do. If the mailbox pointer is NULL, it returns > normally (after timing out or getting woken up); otherwise > an upcall is scheduled. > > -- > Dan Eischen > > _______________________________________________ > 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 Sun Apr 6 23:05:58 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 2954137B401; Sun, 6 Apr 2003 23:05:58 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5098343FAF; Sun, 6 Apr 2003 23:05:57 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003040706055500300p5a3ve>; Mon, 7 Apr 2003 06:05:56 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA58060; Sun, 6 Apr 2003 23:05:54 -0700 (PDT) Date: Sun, 6 Apr 2003 23:05:52 -0700 (PDT) From: Julian Elischer To: "M. Warner Losh" In-Reply-To: <20030406.221733.12213570.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@FreeBSD.ORG cc: core@FreeBSD.ORG cc: davidxu@FreeBSD.ORG cc: eischen@pcnet1.pcnet.com Subject: Re: KSE signals broken by 1:1 commit. 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, 07 Apr 2003 06:05:58 -0000 On Sun, 6 Apr 2003, M. Warner Losh wrote: > Julian, > > thanks for your message to core, but despite the included > text, it is unclear what you want to do. Do you want a blank check to > break things, or do is there a specific fix that was referred to > elsewhere in the thread that was absent from the quoted material. > > Warner > We are in a bind.. Jeff has committed changes that have broken the KSE view of signals. however he is out of the picture for a week now. This means that we can not pass our changes past him as we try fix it. This is made more difficult because it appears that 1:1 threads is broken at the moment, (see mail comments in -current), so we can not test our changes against the 1:1 threads code. All I want is a comment that assuming we take care, if jeff gets back and finds that we've broken something for him, that we are not nailed to a tree for it. julian From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 23:13:09 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 64D5F37B401; Sun, 6 Apr 2003 23:13:09 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5BC043F3F; Sun, 6 Apr 2003 23:13:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc53.attbi.com (rwcrmhc53) with ESMTP id <20030407061308053002lvgde>; Mon, 7 Apr 2003 06:13:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA58098; Sun, 6 Apr 2003 23:13:07 -0700 (PDT) Date: Sun, 6 Apr 2003 23:13:05 -0700 (PDT) From: Julian Elischer To: Jeff Roberson In-Reply-To: <20030407010642.E86645-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org cc: core@freebsd.org cc: David Xu Subject: Re: KSE signals broken by 1:1 commit. 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, 07 Apr 2003 06:13:09 -0000 Hey, you're back! I thought you were away for a few more days. On Mon, 7 Apr 2003, Jeff Roberson wrote: > > I suspect that it can wait as well. I had reports from a user that this > didn't break kse but I didn't specifically test it myself. People are > using thr now though so I'd hope we could avoid breaking it. KSE signals > didn't work well enough at the time that I commited thr to be too > concerned. It seemed as if more work was required to get it right anyway. > > Could you please tell me exactly what you want and let me implement it > instead of backing out working code. If you just want a per process or > kseg mask we can do that although I'm not sure if this is correct. > > Really julian, after all your complaints about people asking you to > backout code that broke the build I'd think you'd be a little more > reasonable. I'm not asking for a backout.. I just want to be not nailed to a tree if it turnes out that we cause some side effects in 1:1 when we try fix the broken-ness introduced by it. if you are available, We can pass patches past you so the whole question is moot. I was worried because I thought you were not available. > > Cheers, > Jeff > > From owner-freebsd-threads@FreeBSD.ORG Sun Apr 6 23:39:02 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 2C43C37B401 for ; Sun, 6 Apr 2003 23:39:02 -0700 (PDT) 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 BB31543F3F for ; Sun, 6 Apr 2003 23:38:59 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQPJNW; Mon, 7 Apr 2003 14:24:33 +0800 Message-ID: <01f801c2fcd0$952c9800$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Mon, 7 Apr 2003 14:40:30 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01F6_01C2FD13.A34836E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 07 Apr 2003 06:39:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01F6_01C2FD13.A34836E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Sunday, April 06, 2003 8:39 PM Subject: Re: PS_BLOCKED > I forgot to mention it, but I think I found a kernel bug also. > Sometimes when the kernel exports a context to the UTS the > %gs register isn't set; it doesn't seem to be saved in some > instances. I think it might only be when a kernel thread > is swapped out (without blocking). Does %gs always get saved, > even if the thread is interrupted by an interrupt? Please test the attached patch to see if %gs problem is fixed. David Xu ------=_NextPart_000_01F6_01C2FD13.A34836E0 Content-Type: application/octet-stream; name="kern_thread.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="kern_thread.c.diff" Index: kern_thread.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v=0A= retrieving revision 1.112=0A= diff -u -r1.112 kern_thread.c=0A= --- kern_thread.c 2 Apr 2003 23:53:29 -0000 1.112=0A= +++ kern_thread.c 7 Apr 2003 06:35:08 -0000=0A= @@ -1242,7 +1242,9 @@=0A= PROC_UNLOCK(p);=0A= td->td_kse =3D NULL;=0A= td->td_state =3D TDS_INACTIVE;=0A= +#if 0=0A= td->td_proc =3D NULL;=0A= +#endif=0A= td->td_ksegrp =3D NULL;=0A= td->td_last_kse =3D NULL;=0A= PCPU_SET(deadthread, td);=0A= @@ -1395,13 +1397,6 @@=0A= bzero(&spare->td_startzero,=0A= (unsigned)RANGEOF(struct thread, td_startzero, td_endzero));=0A= spare->td_proc =3D td->td_proc;=0A= - /* Setup PCB and fork address */=0A= - cpu_set_upcall(spare, td->td_pcb);=0A= - /*=0A= - * XXXKSE do we really need this? (default values for the=0A= - * frame).=0A= - */=0A= - bcopy(td->td_frame, spare->td_frame, sizeof(struct trapframe));=0A= spare->td_ucred =3D crhold(td->td_ucred);=0A= }=0A= =0A= @@ -1433,6 +1428,9 @@=0A= bcopy(&td->td_startcopy, &td2->td_startcopy,=0A= (unsigned) RANGEOF(struct thread, td_startcopy, td_endcopy));=0A= thread_link(td2, ku->ku_ksegrp);=0A= + /* inherit blocked thread's context */=0A= + bcopy(td->td_frame, td2->td_frame, sizeof(struct trapframe));=0A= + cpu_set_upcall(td2, td->td_pcb);=0A= /* Let the new thread become owner of the upcall */=0A= ku->ku_owner =3D td2;=0A= td2->td_upcall =3D ku;=0A= ------=_NextPart_000_01F6_01C2FD13.A34836E0-- From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 00:24:54 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 14B6B37B401; Mon, 7 Apr 2003 00:24:54 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1251C43F3F; Mon, 7 Apr 2003 00:24:53 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h377OmA7089595; Mon, 7 Apr 2003 01:24:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 07 Apr 2003 01:23:15 -0600 (MDT) Message-Id: <20030407.012315.52907595.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: References: <20030406.221733.12213570.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-threads@FreeBSD.ORG cc: core@FreeBSD.ORG cc: davidxu@FreeBSD.ORG cc: eischen@pcnet1.pcnet.com Subject: Re: KSE signals broken by 1:1 commit. 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, 07 Apr 2003 07:24:54 -0000 In message: Julian Elischer writes: : We are in a bind.. : Jeff has committed changes that have broken the KSE view of signals. : however he is out of the picture for a week now. : This means that we can not pass our changes past him as we try fix it. : This is made more difficult because it appears that 1:1 threads is : broken at the moment, (see mail comments in -current), Patches have been posted. Have you tried them yet? : so we can not test our changes against the 1:1 threads code. This is related to the LAZY stuff that was committed. : All I want is a comment that assuming we take care, if jeff gets back : and finds that we've broken something for him, that we are not : nailed to a tree for it. Jeff's mail said he'd be gone only 3 more days. Things for most people aren't broken, so there's no need to rush, imho. I also think Jeff has limited access to the net, so he should be able to review things. I don't think that there's an urgent need for core to override the normal workings of the project at this time. See if you can catch him with this limited access. I'm uneasy about granting an exception to the rules when I haven't even seen a proposed patch. That's just my personal opinion. Warner From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 00:37:05 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 6809B37B401; Mon, 7 Apr 2003 00:37:05 -0700 (PDT) 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 75D6343F3F; Mon, 7 Apr 2003 00:37:02 -0700 (PDT) (envelope-from davidxu@viatech.com.cn) Received: from davidw2k (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 HLDQPJTJ; Mon, 7 Apr 2003 15:22:32 +0800 Message-ID: <000501c2fcd8$aee16de0$f001a8c0@davidw2k> From: "David Xu" To: , "M. Warner Losh" References: <20030406.221733.12213570.imp@bsdimp.com> <20030407.012315.52907595.imp@bsdimp.com> Date: Mon, 7 Apr 2003 15:38:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: core@FreeBSD.ORG cc: eischen@pcnet1.pcnet.com cc: freebsd-threads@FreeBSD.ORG Subject: Re: KSE signals broken by 1:1 commit. 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, 07 Apr 2003 07:37:05 -0000 ----- Original Message -----=20 From: "M. Warner Losh" To: Cc: ; ; = ; Sent: Monday, April 07, 2003 3:23 PM Subject: Re: KSE signals broken by 1:1 commit. > In message: = > Julian Elischer writes: > : We are in a bind.. > : Jeff has committed changes that have broken the KSE view of signals. > : however he is out of the picture for a week now. > : This means that we can not pass our changes past him as we try fix = it. > : This is made more difficult because it appears that 1:1 threads is > : broken at the moment, (see mail comments in -current), >=20 > Patches have been posted. Have you tried them yet? >=20 > : so we can not test our changes against the 1:1 threads code. >=20 > This is related to the LAZY stuff that was committed. >=20 > : All I want is a comment that assuming we take care, if jeff gets = back=20 > : and finds that we've broken something for him, that we are not=20 > : nailed to a tree for it. >=20 > Jeff's mail said he'd be gone only 3 more days. Things for most > people aren't broken, so there's no need to rush, imho. I also think > Jeff has limited access to the net, so he should be able to review > things. I don't think that there's an urgent need for core to > override the normal workings of the project at this time. See if you > can catch him with this limited access. I'm uneasy about granting an > exception to the rules when I haven't even seen a proposed patch. >=20 > That's just my personal opinion. >=20 > Warner So I don't think you are fair enough! I ever posted a message said that jeff's patch had bug, the bug is signal lost, but he obviously didn't fixed it, and you guy allowed him to commit it, please search arch list about 1:1 thread! I don't think delaying some days of libthr change to kernel would hurt anything, I had reported the problem and why did core still allow him to commit? David Xu From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 01:01:50 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 506E737B401; Mon, 7 Apr 2003 01:01:50 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C30243FBF; Mon, 7 Apr 2003 01:01:49 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <20030407080147002004j9ffe>; Mon, 7 Apr 2003 08:01:48 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA58779; Mon, 7 Apr 2003 01:01:46 -0700 (PDT) Date: Mon, 7 Apr 2003 01:01:45 -0700 (PDT) From: Julian Elischer To: "M. Warner Losh" In-Reply-To: <20030407.012315.52907595.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@FreeBSD.ORG cc: core@FreeBSD.ORG cc: davidxu@FreeBSD.ORG cc: eischen@pcnet1.pcnet.com Subject: Re: KSE signals broken by 1:1 commit. 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, 07 Apr 2003 08:01:50 -0000 On Mon, 7 Apr 2003, M. Warner Losh wrote: > In message: > Julian Elischer writes: > : We are in a bind.. > : Jeff has committed changes that have broken the KSE view of signals. > : however he is out of the picture for a week now. > : This means that we can not pass our changes past him as we try fix it. > : This is made more difficult because it appears that 1:1 threads is > : broken at the moment, (see mail comments in -current), > > Patches have been posted. Have you tried them yet? > > : so we can not test our changes against the 1:1 threads code. > > This is related to the LAZY stuff that was committed. > > : All I want is a comment that assuming we take care, if jeff gets back > : and finds that we've broken something for him, that we are not > : nailed to a tree for it. > > Jeff's mail said he'd be gone only 3 more days. Things for most > people aren't broken, so there's no need to rush, imho. I also think > Jeff has limited access to the net, so he should be able to review > things. I don't think that there's an urgent need for core to > override the normal workings of the project at this time. See if you > can catch him with this limited access. I'm uneasy about granting an > exception to the rules when I haven't even seen a proposed patch. > > That's just my personal opinion. Actually i thought he was away for longer and I thought he had no access. if he has access we'll try run things past him first.. > > Warner > From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 04:37:09 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 A358F37B48F for ; Mon, 7 Apr 2003 04:37:08 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21E7B43FDF for ; Mon, 7 Apr 2003 04:37:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0041.cvx22-bradley.dialup.earthlink.net ([209.179.198.41] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 192Uvw-0007iw-00; Mon, 07 Apr 2003 04:37:05 -0700 Message-ID: <3E91628D.6D0D7D3C@mindspring.com> Date: Mon, 07 Apr 2003 04:35:41 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Sysoev References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d64f59b3a9565961bf7ba04523a81f63548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: freebsd-threads@freebsd.org Subject: Re: libc_r and non-blocking disk I/O 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, 07 Apr 2003 11:37:09 -0000 [ Moved to freebsd-threads, where it should have been posted in the first place ] Igor Sysoev wrote: > I mean that if FreeBSD would support select() for disk files there can > be the programs that will use this feature directly without any wrappers > and these programs would have the portability problems. Select will simply return "true" for disk files on all systems that don't support the idea of "disk I/O in progress/disk I/O complete". Such systems would eat the 20ms stall that FreeBSD is eating today in lib_r's non-blocking I/O case. Therefore code written to expect this behaviour will work portably on all systems; as you note, worst case, there's an extra (useless) call to select(), which harms nothing. > It's something like some Linux programs use a specific signal > behaviour of Linux clone()d pthreads. We could enumerate portability issues until we has 5 foot beards; a benign select() is much less of an issue than, for example, the fact that Linux programmers often fail to bzero() sockaddr_in's they declare on the stack, because Linux works without you doing that, and FreeBSD, SVR4, Solaris, etc., do not. I don't think it's useful to call a benign select() a "portability problem"; certainly, it's not in the same class as malignant portability issues with signals or sockaddr_in's, etc.. -- Terry From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 04:53:32 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 E5B0D37B401; Mon, 7 Apr 2003 04:53:32 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CADB43FB1; Mon, 7 Apr 2003 04:53:32 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h37BrNBg012557; Mon, 7 Apr 2003 07:53:23 -0400 (EDT) Received: from localhost (eischen@localhost)h37BrLc3012552; Mon, 7 Apr 2003 07:53:23 -0400 (EDT) Date: Mon, 7 Apr 2003 07:53:21 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED 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, 07 Apr 2003 11:53:33 -0000 On Sun, 6 Apr 2003, Julian Elischer wrote: > > On Sun, 6 Apr 2003, Daniel Eischen wrote: > > > On Sun, 6 Apr 2003, Julian Elischer wrote: > > > > > > If you have this behaviour, please make it an option. Possibly > > > One way to do this would be to call kse_create, with the > > > 'new-ksegrp' flag set but the mailbox pointer set to NULL. > > > > > > However why do you want to use kse_release for this. > > > If you have only one thread in the KSEGRP then I'd call this > > > "usleep()". > > > > It's so that the common code (called by both scope system > > threads and scope process threads) can be the same. I don't > > want to have to add checks all over the place to see if the > > KSE is bound to a thread or not. Also, nanosleep doesn't > > work well because you can't wake it up with a KSE mailbox > > (kse_wakeup), plus there's a race condition if you try and > > wake it up before it actually gets to the kernel to sleep. > > The kse_wakeup() call is latched, so if it gets to the kernel > > first, the next kse_release() will notice it. > > you cannot wake up a thread with no upcall mailbox using kse_wakeup > because there is no thread mailbox address to match. There is a kse mailbox, but no thread mailbox. I'm trying to wakeup a KSE. What I do for multiple threaded KSEs is: upcall_start(struct kse_mailbox *kse_mbox) { struct kse *curkse = (struct kse *)kse_mbx->km_udata; check_completed(kse); check_waitq(kse); ... while ((td_run = runq_first(kse->k_kseg) == NULL) { get_smallest_thread_wakeup_time(kse, &time_to_sleep); kse->k_waiting = 1; kse_release(&time_to_sleep) } /* switch to thread td_run */ } Although, for multiple threaded KSEs, the "while" loop only executes once because kse_release just causes another upcall. If another KSE makes a thread runnable in the first KSEs KSEG's runq, then it wakes up that KSE: _thr_setrunnable(struct kse *curkse, struct pthread *thread) { SCHED_LOCK(curkse); runq_insert(thread->kseg, thread); SCHED_UNLOCK(curkse); if ((thread->kse->k_kseg != curkse->k_kseg) && (thread->kse->k_waiting != 0)) { thread->kse->k_waiting = 0; kse_wakeup(&thread->kse->k_mbox); } } or something like that. For a single threaded KSE/KSEG, I don't want the upcall but I still want to use kse_release(). I need to be able to wakeup that KSE so that it may continue it's thread (it could be the thread was in pthread_cond_wait() and it was signalled by a thread in another KSE). And I don't want upcalls on this KSE because there is only one thread; I don't want the overhead of the upcall and its stack. And in order to prevent upcalls, I have to make sure the kse mailbox has NULL in km_curthread. That's the solution I'm looking for. I think kse_wakeup() should be tweakable so that I don't get an upcall. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 06:06:30 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 2D82937B401; Mon, 7 Apr 2003 06:06:30 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48ED743FA3; Mon, 7 Apr 2003 06:06:28 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h37D6NUp090097; Mon, 7 Apr 2003 06:06:24 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <001e01c2fd07$20b55bb0$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" , "Julian Elischer" References: Date: Mon, 7 Apr 2003 21:10:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: freebsd-threads@freebsd.org Subject: Re: PS_BLOCKED X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2003 13:06:30 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "Julian Elischer" Cc: "David Xu" ; Sent: Monday, April 07, 2003 7:53 PM Subject: Re: PS_BLOCKED > On Sun, 6 Apr 2003, Julian Elischer wrote: > >=20 > > On Sun, 6 Apr 2003, Daniel Eischen wrote: > >=20 > > > On Sun, 6 Apr 2003, Julian Elischer wrote: > > > >=20 > > > > If you have this behaviour, please make it an option. Possibly > > > > One way to do this would be to call kse_create, with the > > > > 'new-ksegrp' flag set but the mailbox pointer set to NULL. > > > >=20 > > > > However why do you want to use kse_release for this. > > > > If you have only one thread in the KSEGRP then I'd call this > > > > "usleep()". > > >=20 > > > It's so that the common code (called by both scope system > > > threads and scope process threads) can be the same. I don't > > > want to have to add checks all over the place to see if the > > > KSE is bound to a thread or not. Also, nanosleep doesn't > > > work well because you can't wake it up with a KSE mailbox > > > (kse_wakeup), plus there's a race condition if you try and > > > wake it up before it actually gets to the kernel to sleep. > > > The kse_wakeup() call is latched, so if it gets to the kernel > > > first, the next kse_release() will notice it. > >=20 > > you cannot wake up a thread with no upcall mailbox using kse_wakeup > > because there is no thread mailbox address to match. >=20 > There is a kse mailbox, but no thread mailbox. I'm trying to > wakeup a KSE. What I do for multiple threaded KSEs is: >=20 > upcall_start(struct kse_mailbox *kse_mbox) > { > struct kse *curkse =3D (struct kse *)kse_mbx->km_udata; >=20 > check_completed(kse); > check_waitq(kse); > ... >=20 > while ((td_run =3D runq_first(kse->k_kseg) =3D=3D NULL) { > get_smallest_thread_wakeup_time(kse, &time_to_sleep); > kse->k_waiting =3D 1; > kse_release(&time_to_sleep) > } > /* switch to thread td_run */ > } >=20 > Although, for multiple threaded KSEs, the "while" loop > only executes once because kse_release just causes another > upcall. If another KSE makes a thread runnable in the > first KSEs KSEG's runq, then it wakes up that KSE: >=20 > _thr_setrunnable(struct kse *curkse, struct pthread *thread) > { > SCHED_LOCK(curkse); > runq_insert(thread->kseg, thread); > SCHED_UNLOCK(curkse); > if ((thread->kse->k_kseg !=3D curkse->k_kseg) && > (thread->kse->k_waiting !=3D 0)) { > thread->kse->k_waiting =3D 0; > kse_wakeup(&thread->kse->k_mbox); > } > } >=20 > or something like that. >=20 > For a single threaded KSE/KSEG, I don't want the upcall but I > still want to use kse_release(). I need to be able to wakeup > that KSE so that it may continue it's thread (it could be the > thread was in pthread_cond_wait() and it was signalled by > a thread in another KSE). And I don't want upcalls on this > KSE because there is only one thread; I don't want the overhead > of the upcall and its stack. And in order to prevent upcalls, > I have to make sure the kse mailbox has NULL in km_curthread. >=20 > That's the solution I'm looking for. I think kse_wakeup() > should be tweakable so that I don't get an upcall. >=20 Yes, I think kse_release() should be tweaked. however, because the thread is no longer an upcalling thread, so how do I deliver signal ? I still prefer to deliver signal in legacy mode, especially for = synchronized signals. > --=20 > Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 11:07:16 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 A17B737B404; Mon, 7 Apr 2003 11:07:16 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B62CC43FB1; Mon, 7 Apr 2003 11:07:15 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h37I79Bg005310; Mon, 7 Apr 2003 14:07:09 -0400 (EDT) Received: from localhost (eischen@localhost)h37I78gY005305; Mon, 7 Apr 2003 14:07:08 -0400 (EDT) Date: Mon, 7 Apr 2003 14:07:08 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Scope system threads (was Re: PS_BLOCKED) 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, 07 Apr 2003 18:07:17 -0000 Rethinking scope system threads a bit... Here's what I'd like for scope system threads: o No separate upcall stack; only ever gets one upcall after kse_create() is called. o Still has a thread mailbox in which the lone thread's signal mask is placed. o The UTS can deliver signals to scope system threads with kse_thr_interrupt(&scope_system_thread->tmbx, sig) or equivalent. Since there is no upcall stack, you can't make an upcall with kse_mbox->km_sigscaught; you need to send it a signal just like it was a regular non-KSE thread. o Can wait for KSE events from other KSE/KSEGs with kse_release(&ts). After receiving a wakeup or timing out, kse_release just returns normally -- no upcall. Typically, we need to wait for low-level locks or pthread_cond_[timed]wait(). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Apr 7 18:03:33 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 A5F0137B401 for ; Mon, 7 Apr 2003 18:03:33 -0700 (PDT) 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 4EE5F43FAF for ; Mon, 7 Apr 2003 18:03:32 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQPMQ3; Tue, 8 Apr 2003 08:49:15 +0800 Message-ID: <006601c2fd6a$e2b79d00$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" , "Julian Elischer" References: Date: Tue, 8 Apr 2003 09:05:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 08 Apr 2003 01:03:34 -0000 Daniel, These are optimizations, right? Could we stablize the libpthread before optimizing it? Is per-kse problem resolved? I don't stick to this,=20 and if you think it should be resolved now, I would like to work on it. David Xu ----- Original Message -----=20 From: "Daniel Eischen" To: "Julian Elischer" Cc: "David Xu" ; Sent: Tuesday, April 08, 2003 2:07 AM Subject: Scope system threads (was Re: PS_BLOCKED) > Rethinking scope system threads a bit... >=20 > Here's what I'd like for scope system threads: >=20 > o No separate upcall stack; only ever gets one upcall > after kse_create() is called. > o Still has a thread mailbox in which the lone thread's > signal mask is placed. > o The UTS can deliver signals to scope system threads > with kse_thr_interrupt(&scope_system_thread->tmbx, sig) > or equivalent. Since there is no upcall stack, you > can't make an upcall with kse_mbox->km_sigscaught; you > need to send it a signal just like it was a regular > non-KSE thread. > o Can wait for KSE events from other KSE/KSEGs with > kse_release(&ts). After receiving a wakeup or timing > out, kse_release just returns normally -- no upcall. > Typically, we need to wait for low-level locks or > pthread_cond_[timed]wait(). >=20 > --=20 > Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Tue Apr 8 21:26:47 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 2AE0E37B401; Tue, 8 Apr 2003 21:26:47 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7DE743F75; Tue, 8 Apr 2003 21:26:45 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h394QeBg017723; Wed, 9 Apr 2003 00:26:40 -0400 (EDT) Received: from localhost (eischen@localhost)h394QdIO017718; Wed, 9 Apr 2003 00:26:39 -0400 (EDT) Date: Wed, 9 Apr 2003 00:26:39 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <006601c2fd6a$e2b79d00$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 09 Apr 2003 04:26:47 -0000 On Tue, 8 Apr 2003, David Xu wrote: > Daniel, > > These are optimizations, right? For the most part, yes. But I thought I'd enumerate what I'd like to see. > Could we stablize the libpthread before optimizing it? > Is per-kse problem resolved? I don't stick to this, I'm working on it now. It seems to be working, but I've got to go through the rest of the files to make sure we don't assume that thread->kse is consistent. > and if you think it should be resolved now, I would like to > work on it. There are two things that I know of that need fixing/looking at. One is signals which we've already talked about. The other is getting the remaining ACE tests to pass. There seems to be 3 or 4 that fail and I can't seem to follow the C++ code well enough to figure out where. Have you ever built ACE? I've got an older version that I'm using (version 5.2 I think). My patches to get it to compile are at: http://people.freebsd.org/~deischen/ace5.2_patches If a call to sigqueue() in the source code causes a compile failure, just change it to kill(). Read the top-level ACE_INSTALL file; you have to add a couple of links before compiling. Also, it wouldn't build from the top-level; I just cd'd into ACE_Wrappers/ace and did a gmake there, and then into ACE_Wrappers/tests and also gmake. If you could debug those that would help a lot. I'll get another patch set up as soon as I can. I'd like to commit as soon as we get signals and the ACE bugs figured out. Then we can work on getting multiple KSEs and KSEGs going. The code is mostly there; probably needs to be reworked a bit (along with more debugging). -- Dan Eischen > > David Xu > > ----- Original Message ----- > From: "Daniel Eischen" > To: "Julian Elischer" > Cc: "David Xu" ; > Sent: Tuesday, April 08, 2003 2:07 AM > Subject: Scope system threads (was Re: PS_BLOCKED) > > > > Rethinking scope system threads a bit... > > > > Here's what I'd like for scope system threads: > > > > o No separate upcall stack; only ever gets one upcall > > after kse_create() is called. > > o Still has a thread mailbox in which the lone thread's > > signal mask is placed. > > o The UTS can deliver signals to scope system threads > > with kse_thr_interrupt(&scope_system_thread->tmbx, sig) > > or equivalent. Since there is no upcall stack, you > > can't make an upcall with kse_mbox->km_sigscaught; you > > need to send it a signal just like it was a regular > > non-KSE thread. > > o Can wait for KSE events from other KSE/KSEGs with > > kse_release(&ts). After receiving a wakeup or timing > > out, kse_release just returns normally -- no upcall. > > Typically, we need to wait for low-level locks or > > pthread_cond_[timed]wait(). > > > > -- > > Dan Eischen > From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 02:24: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 CF8F037B401 for ; Wed, 9 Apr 2003 02:24:44 -0700 (PDT) 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 2BFF543FAF for ; Wed, 9 Apr 2003 02:24:38 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQPSCT; Wed, 9 Apr 2003 17:10:29 +0800 Message-ID: <002c01c2fe7a$0a1f16b0$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Wed, 9 Apr 2003 17:26:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 09 Apr 2003 09:24:45 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: "Julian Elischer" ; = Sent: Wednesday, April 09, 2003 12:26 PM Subject: Re: Scope system threads (was Re: PS_BLOCKED) > On Tue, 8 Apr 2003, David Xu wrote: >=20 > > Daniel, > >=20 > > These are optimizations, right? >=20 > For the most part, yes. But I thought I'd enumerate what I'd > like to see. >=20 > > Could we stablize the libpthread before optimizing it? > > Is per-kse problem resolved? I don't stick to this,=20 >=20 > I'm working on it now. It seems to be working, but I've got to go > through the rest of the files to make sure we don't assume that > thread->kse is consistent. >=20 > > and if you think it should be resolved now, I would like to > > work on it. >=20 > There are two things that I know of that need fixing/looking at. > One is signals which we've already talked about. The other is > getting the remaining ACE tests to pass. There seems to be > 3 or 4 that fail and I can't seem to follow the C++ code well > enough to figure out where. Have you ever built ACE? I've > got an older version that I'm using (version 5.2 I think). > My patches to get it to compile are at: >=20 > http://people.freebsd.org/~deischen/ace5.2_patches >=20 > If a call to sigqueue() in the source code causes a compile failure, > just change it to kill(). Read the top-level ACE_INSTALL file; > you have to add a couple of links before compiling. Also, it > wouldn't build from the top-level; I just cd'd into > ACE_Wrappers/ace and did a gmake there, and then into > ACE_Wrappers/tests and also gmake. >=20 > If you could debug those that would help a lot. >=20 OK, I can use C++. I did ever use ACE, I will try ACE 5.2. > I'll get another patch set up as soon as I can. I'd like to > commit as soon as we get signals and the ACE bugs figured out. > Then we can work on getting multiple KSEs and KSEGs going. > The code is mostly there; probably needs to be reworked a bit > (along with more debugging). >=20 > --=20 > Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 04:55:22 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 1F68237B401; Wed, 9 Apr 2003 04:55:22 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F8943FBD; Wed, 9 Apr 2003 04:55:21 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0033.cvx22-bradley.dialup.earthlink.net ([209.179.198.33] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 193EAK-0007aw-00; Wed, 09 Apr 2003 04:54:57 -0700 Message-ID: <3E940993.FBAFFD70@mindspring.com> Date: Wed, 09 Apr 2003 04:52:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Semenyaka References: <20030408164614.GA7236@comp.chem.msu.su> <20030408194944.GA43822@nagual.pp.ru> <20030409112047.GB33265@snark.ratmir.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44782f05b6ec796e5766c71405451c76b3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: "Andrey A. Chernov" cc: Yar Tikhiy cc: threads@freebsd.org Subject: Re: termios & non-blocking I/O 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, 09 Apr 2003 11:55:22 -0000 [ ... moved to -threads mailing list, instead of -arch ... ] Alex Semenyaka wrote: > On Tue, Apr 08, 2003 at 11:49:44PM +0400, Andrey A. Chernov wrote: > > IEEE Std 1003.1-200x does not specify whether the setting of O_NONBLOCK > > takes precedence over MIN or TIME settings. Therefore, if O_NONBLOCK is > > set, read( ) may return immediately, regardless of the setting of MIN or > > TIME. Also, if no data is available, read( ) may either return 0, or > > return -1 with errno set to [EAGAIN]. > > Right you are, but the question is a little bit different, namely - what is > _better_ to do: to return 0 or to return -1/EAGAIN. -1/EAGAIN. As was pointed out in Andrey Chernov's posting, the place to fix this is libc_r, not the kernel, since the kernel is doing something permissable, and the side effect you are seeing is a result of your use of libc_r. > Now the first choice > is implemented. And the point IS that in multi-thread environment with > utheads such implementation leads to BAD results. Probably the correct thing to do is to use a blocking thread, instead of one that uses VMIN/VTIME to poll the keyboard in the first place. In other words, an input processing thread. Normally, this will only be a problem if someone tries to add a thread to do some additional processing in some legacy code, without properly maintaining the legacy code. The main problem you will face, if you try to do this in the kernel instead of libc_r, is that each time you call the read, if it behaved the second way, you would stall all threads in the process for VTIME, and you're going to have a hard time getting people to sign off on blocking all threads because one thread makes some call and the kernel captures it for a long latency. This is remarkably similar to the recent discussion about the blocking of all threads in a libc_r program when taking a page fault. -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 05:34:34 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 0D5BE37B401; Wed, 9 Apr 2003 05:34:34 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9E9443F85; Wed, 9 Apr 2003 05:34:32 -0700 (PDT) (envelope-from alexs@snark.ratmir.ru) Received: from snark.ratmir.ru (alexs@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h39CYVDR033760; Wed, 9 Apr 2003 16:34:31 +0400 (MSD) (envelope-from alexs@snark.ratmir.ru) Received: (from alexs@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h39CYVmw033759; Wed, 9 Apr 2003 16:34:31 +0400 (MSD) Date: Wed, 9 Apr 2003 16:34:31 +0400 From: Alex Semenyaka To: Terry Lambert Message-ID: <20030409123431.GD33144@snark.ratmir.ru> References: <20030408164614.GA7236@comp.chem.msu.su> <20030409044301.J628@gamplex.bde.org> <20030408194944.GA43822@nagual.pp.ru> <20030409112047.GB33265@snark.ratmir.ru> <3E940993.FBAFFD70@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E940993.FBAFFD70@mindspring.com> User-Agent: Mutt/1.5.4i cc: "Andrey A. Chernov" cc: Yar Tikhiy cc: Alex Semenyaka cc: threads@freebsd.org Subject: Re: termios & non-blocking I/O 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, 09 Apr 2003 12:34:34 -0000 On Wed, Apr 09, 2003 at 04:52:51AM -0700, Terry Lambert wrote: >> On Tue, Apr 08, 2003 at 11:49:44PM +0400, Andrey A. Chernov wrote: > >> IEEE Std 1003.1-200x does not specify whether the setting of O_NONBLOCK > >> takes precedence over MIN or TIME settings. Therefore, if O_NONBLOCK is > >> set, read( ) may return immediately, regardless of the setting of MIN or > >> TIME. Also, if no data is available, read( ) may either return 0, or > >> return -1 with errno set to [EAGAIN]. >> Right you are, but the question is a little bit different, namely - what is >> _better_ to do: to return 0 or to return -1/EAGAIN. > As was pointed out in Andrey Chernov's posting, the place to fix > this is libc_r, not the kernel, since the kernel is doing something > permissable, and the side effect you are seeing is a result of your > use of libc_r. Yes it is permissable, it is just in the disagreement with the behaviour when MIN>0 and TIME=0. Don't you think the behaviour in the (TIME=0, MIN>0) and (TIME>0, MIN=0) should be consistent somehow? Then, changing the kernel behavour is simple, straightforward and also PERFECTLY permissable while tracing the situation with the descriptor mode in libc_r is not so simple. To be fair such tracing might be a difficult task. >> Now the first choice >> is implemented. And the point IS that in multi-thread environment with >> utheads such implementation leads to BAD results. > The main problem you will face, if you try to do this in the > kernel instead of libc_r, is that each time you call the read, > if it behaved the second way, you would stall all threads in > the process for VTIME, and you're going to have a hard time No, sorry, you have missed my point. Sure I do NOT propose to block the input when TIME>0. I propose to return -1/EAGAIN (as in the MIN>0 case) instead of 0 (as it is done now). That is what I called "the second way". And in this case both libc_r and program can easely distinct between EOF and nothing-to-read situation and handle them properly. Also all other threads will not be stucked. Once again: -1/EAGAIN is absolutely legal as well generally and more correct here, that's what I am saying. SY, Alex From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 06:05:48 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 2C16937B401; Wed, 9 Apr 2003 06:05:48 -0700 (PDT) Received: from h00609772adf0.ne.client2.attbi.com (h00609772adf0.ne.client2.attbi.com [24.61.43.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17C7C43F3F; Wed, 9 Apr 2003 06:05:47 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from h00609772adf0.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1])h39D5mcJ040559; Wed, 9 Apr 2003 09:05:48 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)h39D5mN7040558; Wed, 9 Apr 2003 09:05:48 -0400 (EDT) Date: Wed, 9 Apr 2003 09:05:47 -0400 From: Craig Rodrigues To: David Xu Message-ID: <20030409130547.GB40511@attbi.com> References: <002c01c2fe7a$0a1f16b0$f001a8c0@davidw2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002c01c2fe7a$0a1f16b0$f001a8c0@davidw2k> User-Agent: Mutt/1.4i cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 09 Apr 2003 13:05:48 -0000 On Wed, Apr 09, 2003 at 05:26:02PM +0800, David Xu wrote: > > If you could debug those that would help a lot. > > > OK, I can use C++. I did ever use ACE, I will try ACE 5.2. If you can, you should try ACE 5.3.1 from: http://deuce.doc.wustl.edu/Download.html I submitted a lot of FreeBSD patches to versions of ACE > 5.2. To build ACE: - get it from the above URL - extract the ACE package, everything will be under an ACE_wrappers directory - set the ACE_ROOT environment variable to: {full path}/ACE_wrappers - cd $ACE_ROOT - gmake -- Craig Rodrigues http://home.attbi.com/~rodrigc rodrigc@attbi.com From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 08:19:47 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 E7A1E37B401; Wed, 9 Apr 2003 08:19:47 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46B1F43F85; Wed, 9 Apr 2003 08:19:47 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h39FJhBg010776; Wed, 9 Apr 2003 11:19:43 -0400 (EDT) Received: from localhost (eischen@localhost)h39FJhnR010773; Wed, 9 Apr 2003 11:19:43 -0400 (EDT) Date: Wed, 9 Apr 2003 11:19:43 -0400 (EDT) From: Daniel Eischen To: Craig Rodrigues In-Reply-To: <20030409130547.GB40511@attbi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 09 Apr 2003 15:19:48 -0000 On Wed, 9 Apr 2003, Craig Rodrigues wrote: > On Wed, Apr 09, 2003 at 05:26:02PM +0800, David Xu wrote: > > > If you could debug those that would help a lot. > > > > > OK, I can use C++. I did ever use ACE, I will try ACE 5.2. > > If you can, you should try ACE 5.3.1 from: > http://deuce.doc.wustl.edu/Download.html > > I submitted a lot of FreeBSD patches to versions of ACE > 5.2. Did you look at my patches to see if there are any others that should be submitted? > To build ACE: > - get it from the above URL > - extract the ACE package, everything will be under an ACE_wrappers > directory > - set the ACE_ROOT environment variable to: {full path}/ACE_wrappers > - cd $ACE_ROOT > - gmake -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 08:47: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 620CD37B401 for ; Wed, 9 Apr 2003 08:47:40 -0700 (PDT) Received: from h00609772adf0.ne.client2.attbi.com (h00609772adf0.ne.client2.attbi.com [24.61.43.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CFE443FBD for ; Wed, 9 Apr 2003 08:47:39 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from h00609772adf0.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1])h39FlecJ041155; Wed, 9 Apr 2003 11:47:41 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)h39FleqR041154; Wed, 9 Apr 2003 11:47:40 -0400 (EDT) Date: Wed, 9 Apr 2003 11:47:39 -0400 From: Craig Rodrigues To: Daniel Eischen Message-ID: <20030409154739.GA41117@attbi.com> References: <20030409130547.GB40511@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 09 Apr 2003 15:47:40 -0000 On Wed, Apr 09, 2003 at 11:19:43AM -0400, Daniel Eischen wrote: > Did you look at my patches to see if there are any others that > should be submitted? I never saw your patches before, but from the looks of things, most of what you have I already incorporated in previous patches plus I have made a lot more fixes. There are actually *TONS* of FreeBSD fixes in the latest ACE that are not in 5.2. I am only missing a few small things from your patch like -lkse. If you create a new patch based on the latest ACE, I'll see what I can do about getting it into the ACE cvs repository. I should modify my instructions for building ACE, since they are not complete. To build ACE: - get ACE 5.3.1 from http://deuce.doc.wustl.edu/Download.html - extract the ACE package, everything will be under an ACE_wrappers directory - set the ACE_ROOT environment variable to: {full path}/ACE_wrappers - create a file $ACE_ROOT/ace/config.h with one line: #include "ace/config-freebsd.h" - create a file $ACE_ROOT/include/makeinclude/platform_macros.GNU with one line: include $(ACE_ROOT)/include/makeinclude/platform_freebsd.GNU - cd $ACE_ROOT - gmake -- Craig Rodrigues http://home.attbi.com/~rodrigc rodrigc@attbi.com From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 11:28:25 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 5D2CE37B401 for ; Wed, 9 Apr 2003 11:28:25 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91D2143FA3 for ; Wed, 9 Apr 2003 11:28:24 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h39ISNBg006364; Wed, 9 Apr 2003 14:28:23 -0400 (EDT) Received: from localhost (eischen@localhost)h39ISM5V006360; Wed, 9 Apr 2003 14:28:23 -0400 (EDT) Date: Wed, 9 Apr 2003 14:28:22 -0400 (EDT) From: Daniel Eischen To: Craig Rodrigues In-Reply-To: <20030409154739.GA41117@attbi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 09 Apr 2003 18:28:25 -0000 On Wed, 9 Apr 2003, Craig Rodrigues wrote: > On Wed, Apr 09, 2003 at 11:19:43AM -0400, Daniel Eischen wrote: > > Did you look at my patches to see if there are any others that > > should be submitted? > > I never saw your patches before, but from the looks of things, > most of what you have I already incorporated in previous patches > plus I have made a lot more fixes. There are actually *TONS* > of FreeBSD fixes in the latest ACE that are not in 5.2. > I am only missing a few small things from your patch like -lkse. Yep, I just downloaded 5.3.1. Note that it isn't listed anywhere I can see as 5.3.1, but if you pull down the beta version, that seems to be 5.3.1. > If you create a new patch based on the latest ACE, I'll see what I can > do about getting it into the ACE cvs repository. I built it just fine without modifying anything except -lkse. You don't even need to change that if you just install libkse as libc_r.so.5, but I'd rather test out libkse in small pieces than to have kde blow up in my face :-). > I should modify my instructions for building ACE, since they are not > complete. > > To build ACE: > - get ACE 5.3.1 from http://deuce.doc.wustl.edu/Download.html > - extract the ACE package, everything will be under an ACE_wrappers > directory > - set the ACE_ROOT environment variable to: {full path}/ACE_wrappers > - create a file $ACE_ROOT/ace/config.h with one line: > > #include "ace/config-freebsd.h" I just link config.h to config-freebsd.h. > - create a file $ACE_ROOT/include/makeinclude/platform_macros.GNU with one line: > > include $(ACE_ROOT)/include/makeinclude/platform_freebsd.GNU Same here. > - cd $ACE_ROOT > - gmake And it all seems to build fine. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 15:24:13 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 AF70D37B401; Wed, 9 Apr 2003 15:24:13 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA01F43F85; Wed, 9 Apr 2003 15:24:12 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h39MOCBg009120; Wed, 9 Apr 2003 18:24:12 -0400 (EDT) Received: from localhost (eischen@localhost)h39MOBmU009117; Wed, 9 Apr 2003 18:24:11 -0400 (EDT) Date: Wed, 9 Apr 2003 18:24:11 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 09 Apr 2003 22:24:14 -0000 On Wed, 9 Apr 2003, Daniel Eischen wrote: > I'll get another patch set up as soon as I can. I'd like to It's in place now; same usual location. http://people.freebsd.org/~deischen/libpthread.diffs -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 16:25:41 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 35EB837B401; Wed, 9 Apr 2003 16:25:41 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id D25A443FBD; Wed, 9 Apr 2003 16:25:39 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0163.cvx22-bradley.dialup.earthlink.net ([209.179.198.163] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 193OwR-0002jY-00; Wed, 09 Apr 2003 16:25:20 -0700 Message-ID: <3E94AB82.496681D5@mindspring.com> Date: Wed, 09 Apr 2003 16:23:46 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Semenyaka References: <20030408164614.GA7236@comp.chem.msu.su> <20030409044301.J628@gamplex.bde.org> <20030408194944.GA43822@nagual.pp.ru> <20030409112047.GB33265@snark.ratmir.ru> <3E940993.FBAFFD70@mindspring.com> <20030409123431.GD33144@snark.ratmir.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a475268a311e27c18d2f2b8bb684884c33a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: "Andrey A. Chernov" cc: Yar Tikhiy cc: threads@freebsd.org Subject: Re: termios & non-blocking I/O 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, 09 Apr 2003 23:25:41 -0000 Alex Semenyaka wrote: > Yes it is permissable, it is just in the disagreement with the behaviour > when MIN>0 and TIME=0. Don't you think the behaviour in the (TIME=0, MIN>0) > and (TIME>0, MIN=0) should be consistent somehow? Consistent with what? The cases are: MIN TIME 1) >0 >0 Interbyte timer; after 1 byte received, timer is started; if MIN bytes received before timer is statisfied, return. If another byte is received, timer is reset; if timer expires, read is satisfied. 2) >0 =0 Pending read is not satisfied until MIN bytes received. 3) =0 >0 NOT interbyte timer; read is satisfied on a single byte received or timer expired. 4) =0 =0 Polling read; available bytes up to number of requested bytes is returned, and read is always satisfied. The specification further indicates that the resolution on the TIME timer is .1 *SECOND*. This basically means that, if it is handled in the kernel, case #1 could *block all other threads indefinitely*, up to .1S * MIN, which for MIN=100, TIME=1 is *10 FULL SECONDS*. That's *obviously* unacceptable. I think it is impossible to implement case #1 correctly with NBIO enabled, and would convert it to case #4, and implement the TIME in user space in libc_r. Case #2 is still not correctly handled at all by your proposed change; libc_r work is required to avoid stalling until input is present; the correct return on NBIO is pretty obviously "EAGAIN,-1"; HOWEVER, you may have received *some* input data, but not MIN worth of input data; returning some number < MIN violates the interface contract; so does losing the data. Case #3 is a full read timer for one byte; also not correctly handled in the face of the proposed change. For a TIME=100, we are talking about stalling all threads for 100 seconds; the correct return is Case #4 is polling I/O; it's trivial to implement in libc_r. I think the big issue here is the "short read" case in #2. The correct thing, to me, would be to return the number of bytes read on the NBIO descriptor, and let the libc_r figure out that that number is less than the number requested. > Then, changing the kernel behavour is simple, straightforward and also > PERFECTLY permissable while tracing the situation with the descriptor mode > in libc_r is not so simple. To be fair such tracing might be a difficult > task. Rule of thumb: If it adds latency, which is always annoying; if it can add an arbitray number of seconds of latency, it's unacceptable. > No, sorry, you have missed my point. Sure I do NOT propose to block > the input when TIME>0. I propose to return -1/EAGAIN (as in the > MIN>0 case) instead of 0 (as it is done now). That is what I called > "the second way". And in this case both libc_r and program can > easely distinct between EOF and nothing-to-read situation and handle > them properly. Also all other threads will not be stucked. The problem with this is case #2 with some number of characters less than MIN. For example, let us propose a MIN of 10, with 3 characters pending input at the time the read is called; you have two cases: #1 TIME>0 I argue that this is impossible to implement in the presence of NBIO, since you can not return both the value of the short read, and the fact that the timer would result in a block, simultaneously. Best approach is to cause an error, EAGAIN,-1. #2 TIME=0 I argue that the value of the short read should be returned, rather than an error. At least in this approach, you can identify in libc_r that a short read has occurred, and that the thread must be rescheduled in order to complete the remaining read, up to MIN. These cases are somewhat contrived, in that use of MIN/TIME values, in other words non-canonical input processing, is at odds with the threads model. At best, combining them provides for the ability to poll (#4: an incredibly bad thing in a threads environment, since a user space scheduler will not necessarily ever schedule another thread to run, if there is a polling thread), and the ability to ask for "X or more characters, up to Y, where MIN=Z and the character count to read(2)=Y" (#2). Probably the only legitimate use in the presence of threads is #2, to get "allowed and expected bounded read lengths", and that's the one you want to change so that it won't work any more. -- Terry From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 22:08:35 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 ED29937B401 for ; Wed, 9 Apr 2003 22:08:35 -0700 (PDT) Received: from h00609772adf0.ne.client2.attbi.com (h00609772adf0.ne.client2.attbi.com [24.61.43.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0595943F93 for ; Wed, 9 Apr 2003 22:08:35 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from h00609772adf0.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1])h3A58acJ037072 for ; Thu, 10 Apr 2003 01:08:37 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)h3A58am8037071 for freebsd-threads@freebsd.org; Thu, 10 Apr 2003 01:08:36 -0400 (EDT) Date: Thu, 10 Apr 2003 01:08:35 -0400 From: Craig Rodrigues To: freebsd-threads@freebsd.org Message-ID: <20030410050835.GA37060@attbi.com> References: <20030409154739.GA41117@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 10 Apr 2003 05:08:36 -0000 On Wed, Apr 09, 2003 at 02:28:22PM -0400, Daniel Eischen wrote: > I built it just fine without modifying anything except -lkse. > You don't even need to change that if you just install libkse > as libc_r.so.5, but I'd rather test out libkse in small pieces > than to have kde blow up in my face :-). OK, this is good news. I put a lot of time in patching up ACE to work on FreeBSD, and some of my work also involved submitting patches to FreeBSD. I am glad that > And it all seems to build fine. Now, earlier in this e-mail thread someone mentioned that certain ACE tests were failing. Do these tests fail now with ACE 5.3.1? FreeBSD lacks POSIX real-time signals, which was very troublesome when I was trying to get the ACE Proactor to work properly, because the Proactor uses POSIX AIO + POSIX RT signals. I would really like to see POSIX RT signals on FreeBSD. However, since this is a threads mailing list, I assume you are more interested in the ACE threads tests passing with KSE. Are there any problems there? I am also very interested in how KSE thread priorities work, because thread priorities are used in the TAO Real-time CORBA ORB, which is built on top of ACE. -- Craig Rodrigues http://home.attbi.com/~rodrigc rodrigc@attbi.com From owner-freebsd-threads@FreeBSD.ORG Wed Apr 9 22:58:30 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 6B48937B401 for ; Wed, 9 Apr 2003 22:58:30 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC9F343F3F for ; Wed, 9 Apr 2003 22:58:29 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3A5wQBg007670; Thu, 10 Apr 2003 01:58:26 -0400 (EDT) Received: from localhost (eischen@localhost)h3A5wPJN007665; Thu, 10 Apr 2003 01:58:25 -0400 (EDT) Date: Thu, 10 Apr 2003 01:58:25 -0400 (EDT) From: Daniel Eischen To: Craig Rodrigues In-Reply-To: <20030410050835.GA37060@attbi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 10 Apr 2003 05:58:30 -0000 On Thu, 10 Apr 2003, Craig Rodrigues wrote: > On Wed, Apr 09, 2003 at 02:28:22PM -0400, Daniel Eischen wrote: > > I built it just fine without modifying anything except -lkse. > > You don't even need to change that if you just install libkse > > as libc_r.so.5, but I'd rather test out libkse in small pieces > > than to have kde blow up in my face :-). > > OK, this is good news. I put a lot of time in patching up ACE > to work on FreeBSD, and some of my work also involved submitting > patches to FreeBSD. I am glad that > > > > And it all seems to build fine. > > > Now, earlier in this e-mail thread someone mentioned that certain ACE tests > were failing. Do these tests fail now with ACE 5.3.1? Yes, and perhaps a couple new tests that were added since 5.2. > FreeBSD lacks POSIX real-time signals, which was very troublesome > when I was trying to get the ACE Proactor to work properly, because > the Proactor uses POSIX AIO + POSIX RT signals. I would really > like to see POSIX RT signals on FreeBSD. > > However, since this is a threads mailing list, I assume you > are more interested in the ACE threads tests passing with KSE. > Are there any problems there? Yes, I'm talking about tests that pass with libc_r and don't with libkse. Mostly because we get SEGVs or intentional ACE aborts(). These are most likely bugs in libkse that need to be worked out. > I am also very interested in how KSE thread priorities work, because > thread priorities are used in the TAO Real-time CORBA ORB, which is > built on top of ACE. The mutex test (lib/libpthread/test/mutex_d) passes with my version of libkse. This is a good test of thread priorities. libkse should behave in the same way as libc_r, with the exception that threads could be running in different KSEs so that could affect the order of how threads run. But this is all OK by POSIX semantics (more than one scheduling domain and/or scope system threads) and is under application control. By default, you only get one KSE/KSEG. If you want others, you use pthread_setconcurrency() and/or create scope system threads. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 00:09:04 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 13D0037B401 for ; Thu, 10 Apr 2003 00:09:04 -0700 (PDT) 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 454B843FAF for ; Thu, 10 Apr 2003 00:09:00 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQPV4W; Thu, 10 Apr 2003 14:55:11 +0800 Message-ID: <005001c2ff30$47835e60$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Thu, 10 Apr 2003 15:10:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 10 Apr 2003 07:09:04 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Thursday, April 10, 2003 6:24 AM Subject: Re: Scope system threads (was Re: PS_BLOCKED) > On Wed, 9 Apr 2003, Daniel Eischen wrote: > > I'll get another patch set up as soon as I can. I'd like to >=20 > It's in place now; same usual location. >=20 > http://people.freebsd.org/~deischen/libpthread.diffs >=20 Got it! I have found that %gs is not saved by kernel in trap frame and it brain dead direct loads userland %gs in cpu_switch, it is a bug for threaded program, I can easily crash kernel within few lines code by setting %gs to use LDT in a thread, and invalid the LDT descriptor in another thread, and kernel will crash in cpu_switch()! I am trying to fix it in kernel, but because there is too much code I must look, too easy to crash kernel, It would cost me much time, this is too bad for me, se we can not run multiple kses until the serious bug is fixed. > --=20 > Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 09:20:50 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 90D0937B401 for ; Thu, 10 Apr 2003 09:20:50 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECCA143FB1 for ; Thu, 10 Apr 2003 09:20:49 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.9/8.12.9) with SMTP id h3AGL8YY039750; Thu, 10 Apr 2003 12:21:09 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 10 Apr 2003 12:21:07 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Craig Rodrigues In-Reply-To: <20030410050835.GA37060@attbi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Scope system threads (was Re: PS_BLOCKED) 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, 10 Apr 2003 16:20:50 -0000 On Thu, 10 Apr 2003, Craig Rodrigues wrote: > FreeBSD lacks POSIX real-time signals, which was very troublesome when I > was trying to get the ACE Proactor to work properly, because the > Proactor uses POSIX AIO + POSIX RT signals. I would really like to see > POSIX RT signals on FreeBSD. There was some earlier work done by Juli Mallett to introduce reliable signals, which supported some of the elements of the POSIX realtime signal requirements. However, there were a fair number of implementation details that hadn't been addressed at that point that really needed to be addressed before the changes could be merged (largely related to reliability and stability concerns). I'd be interested in seeing that work brought back to life, perhaps on a Perforce branch. One of the concerns with the reliable signalling bits was that it required more kernel memory allocation, often while holding locks -- I suspect things can be reworked to avoid that burden without too much difficulty. Interestingly, it looked like on some other operating systems the introduction of reliable signaling actually resulted in the potential loss of signals in low memory scenarios :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 22:04:19 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 B129237B40C for ; Thu, 10 Apr 2003 22:04:19 -0700 (PDT) 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 4FB6343FB1 for ; Thu, 10 Apr 2003 22:04:16 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQPZJN; Fri, 11 Apr 2003 12:50:38 +0800 Message-ID: <008001c2ffe8$056584f0$f001a8c0@davidw2k> From: "David Xu" To: References: <20030410201305.0537337B401@hub.freebsd.org> Date: Fri, 11 Apr 2003 13:05:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: patch for %gs saving 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, 11 Apr 2003 05:04:20 -0000 Here is the patch for kernel to save %gs, it works well on my machine. http://people.freebsd.org/~davidxu/i386_gs.diff Daniel, is this the reason in your libpthread patch that doesn't use getcontext syscall ? David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 22:37:22 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 E5FDD37B401; Thu, 10 Apr 2003 22:37:22 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EF5F43F85; Thu, 10 Apr 2003 22:37:22 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 782152A7EA; Thu, 10 Apr 2003 22:37:22 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "David Xu" In-Reply-To: <008001c2ffe8$056584f0$f001a8c0@davidw2k> Date: Thu, 10 Apr 2003 22:37:22 -0700 From: Peter Wemm Message-Id: <20030411053722.782152A7EA@canning.wemm.org> cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 05:37:23 -0000 "David Xu" wrote: > Here is the patch for kernel to save %gs, > it works well on my machine. > http://people.freebsd.org/~davidxu/i386_gs.diff > Daniel, is this the reason in your libpthread > patch that doesn't use getcontext syscall ? To put some background on the issue, there is a reason why we did not do this. %gs is not used by the kernel, so it does not normally need to be saved and restored on every trap into the kernel. Setting a segment register is Really Slow - measured in hundreds of clock cycles. So, we normally only touch %gs when we context switch to a different process that may have a different %gs. Or when one of the context syscalls wants it changed. We cannot avoid touching %fs because we use it for kernel private data. But if it wasn't for that, we wouldn't be touching %fs for regular traps/syscalls/etc either. Bruce Evans understands this better than I do, I would suggest not making this change without talking about it with him first. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 22:55:33 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 B38DF37B401; Thu, 10 Apr 2003 22:55:33 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1437B43FA3; Thu, 10 Apr 2003 22:55:33 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3B5tWBg025974; Fri, 11 Apr 2003 01:55:32 -0400 (EDT) Received: from localhost (eischen@localhost)h3B5tVjl025968; Fri, 11 Apr 2003 01:55:31 -0400 (EDT) Date: Fri, 11 Apr 2003 01:55:31 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <008001c2ffe8$056584f0$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 05:55:34 -0000 On Fri, 11 Apr 2003, David Xu wrote: > Here is the patch for kernel to save %gs, > it works well on my machine. > http://people.freebsd.org/~davidxu/i386_gs.diff Thanks, I'll give it a go. > Daniel, is this the reason in your libpthread > patch that doesn't use getcontext syscall ? No, we already had userland versions of getcontext() so I simply reused them to avoid the system call. That's why THR_GETCONTEXT is a macro; it can be defined to be getcontext() for those archs that don't have userland versions and want to use the system call instead. Note that we still need userland versions of _thread_switch() and _thread_enter_uts() anyways, so writing a userland [gs]etcontext() is probably pretty simple once you have those. Plus, when you get a context in order to make a context for a new thread, you still can't rely on %gs because it may be scheduled on another KSE or the thread could be a scope system thread in which case it be scheduled in another KSEG. So the current %gs isn't necessarily correct for a new thread. Hmm, this raises a good point. Once you set up a thread to run a signal handler, the %gs register has already been set. We have to be sure that the interrupted context and the thread's new (signal) context both have the same %gs and that it runs on the correct KSE. Either that, or we have to be able to change the contexts to be the correct %gs before running the thread and invoking the handler. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 23:00:03 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 7AE9737B401; Thu, 10 Apr 2003 23:00:03 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2DF743F85; Thu, 10 Apr 2003 23:00:02 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3B602Bg026499; Fri, 11 Apr 2003 02:00:02 -0400 (EDT) Received: from localhost (eischen@localhost)h3B601uG026495; Fri, 11 Apr 2003 02:00:01 -0400 (EDT) Date: Fri, 11 Apr 2003 02:00:01 -0400 (EDT) From: Daniel Eischen To: Peter Wemm In-Reply-To: <20030411053722.782152A7EA@canning.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 06:00:03 -0000 On Thu, 10 Apr 2003, Peter Wemm wrote: > "David Xu" wrote: > > Here is the patch for kernel to save %gs, > > it works well on my machine. > > http://people.freebsd.org/~davidxu/i386_gs.diff > > Daniel, is this the reason in your libpthread > > patch that doesn't use getcontext syscall ? > > To put some background on the issue, there is a reason why we did not > do this. %gs is not used by the kernel, so it does not normally need to > be saved and restored on every trap into the kernel. Setting a segment > register is Really Slow - measured in hundreds of clock cycles. > > So, we normally only touch %gs when we context switch to a different process > that may have a different %gs. Or when one of the context syscalls wants > it changed. We cannot avoid touching %fs because we use it for kernel > private data. But if it wasn't for that, we wouldn't be touching > %fs for regular traps/syscalls/etc either. > > Bruce Evans understands this better than I do, I would suggest not making > this change without talking about it with him first. So this is akin to lazy FPU switching? -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 23:00:38 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 E808637B401 for ; Thu, 10 Apr 2003 23:00:38 -0700 (PDT) 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 5F45043F93 for ; Thu, 10 Apr 2003 23:00:37 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQPZQT; Fri, 11 Apr 2003 13:47:00 +0800 Message-ID: <012401c2ffef$e50657e0$f001a8c0@davidw2k> From: "David Xu" To: "Peter Wemm" References: <20030411053722.782152A7EA@canning.wemm.org> Date: Fri, 11 Apr 2003 14:02:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 06:00:39 -0000 ----- Original Message -----=20 From: "Peter Wemm" To: "David Xu" Cc: Sent: Friday, April 11, 2003 1:37 PM Subject: Re: patch for %gs saving=20 > "David Xu" wrote: > > Here is the patch for kernel to save %gs, > > it works well on my machine. > > http://people.freebsd.org/~davidxu/i386_gs.diff > > Daniel, is this the reason in your libpthread > > patch that doesn't use getcontext syscall ? >=20 > To put some background on the issue, there is a reason why we did not > do this. %gs is not used by the kernel, so it does not normally need = to > be saved and restored on every trap into the kernel. Setting a = segment > register is Really Slow - measured in hundreds of clock cycles. >=20 > So, we normally only touch %gs when we context switch to a different = process > that may have a different %gs. Or when one of the context syscalls = wants > it changed. We cannot avoid touching %fs because we use it for kernel > private data. But if it wasn't for that, we wouldn't be touching > %fs for regular traps/syscalls/etc either. >=20 > Bruce Evans understands this better than I do, I would suggest not = making > this change without talking about it with him first. >=20 Yes, I know loading a descriptor is slow, but in real world, such = optimization will be lost in real work noise. And setcontext syscall is broken by = this optimization, userland will fail to set his context in atomic operation, set pcb->gs =3D userland_gs does not work, so the cost is obviously, I = can optimize my patch to only save and restore %gs at trap and interrupt time, when = entering kernel, I can always zero %gs because kernel does not use it, I think = this can reduce clock cycles at context switch, this might be better than current = code which loading %gs at every context switch. > Cheers, > -Peter > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 23:02:10 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 A4D7437B401; Thu, 10 Apr 2003 23:02:10 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEB0743FAF; Thu, 10 Apr 2003 23:02:07 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3B627Bg026748; Fri, 11 Apr 2003 02:02:07 -0400 (EDT) Received: from localhost (eischen@localhost)h3B6273f026745; Fri, 11 Apr 2003 02:02:07 -0400 (EDT) Date: Fri, 11 Apr 2003 02:02:06 -0400 (EDT) From: Daniel Eischen To: Peter Wemm In-Reply-To: <20030411053722.782152A7EA@canning.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 06:02:10 -0000 On Thu, 10 Apr 2003, Peter Wemm wrote: > "David Xu" wrote: > > Here is the patch for kernel to save %gs, > > it works well on my machine. > > http://people.freebsd.org/~davidxu/i386_gs.diff > > Daniel, is this the reason in your libpthread > > patch that doesn't use getcontext syscall ? > > To put some background on the issue, there is a reason why we did not > do this. %gs is not used by the kernel, so it does not normally need to > be saved and restored on every trap into the kernel. Setting a segment > register is Really Slow - measured in hundreds of clock cycles. > > So, we normally only touch %gs when we context switch to a different process > that may have a different %gs. Or when one of the context syscalls wants > it changed. We cannot avoid touching %fs because we use it for kernel > private data. But if it wasn't for that, we wouldn't be touching > %fs for regular traps/syscalls/etc either. > > Bruce Evans understands this better than I do, I would suggest not making > this change without talking about it with him first. BTW, it's not really a big deal for the UTS to restore %gs (or probably whatever it ends up being on other archs) before continuing a thread. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 23:54:09 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 9F53737B401; Thu, 10 Apr 2003 23:54:09 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEBF843F93; Thu, 10 Apr 2003 23:54:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003041106540700300fd40de>; Fri, 11 Apr 2003 06:54:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA94859; Thu, 10 Apr 2003 23:54:06 -0700 (PDT) Date: Thu, 10 Apr 2003 23:54:04 -0700 (PDT) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 06:54:10 -0000 On Fri, 11 Apr 2003, Daniel Eischen wrote: > On Thu, 10 Apr 2003, Peter Wemm wrote: > > > "David Xu" wrote: > > > Here is the patch for kernel to save %gs, > > > it works well on my machine. > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > Daniel, is this the reason in your libpthread > > > patch that doesn't use getcontext syscall ? > > > > To put some background on the issue, there is a reason why we did not > > do this. %gs is not used by the kernel, so it does not normally need to > > be saved and restored on every trap into the kernel. Setting a segment > > register is Really Slow - measured in hundreds of clock cycles. > > > > So, we normally only touch %gs when we context switch to a different process > > that may have a different %gs. Or when one of the context syscalls wants > > it changed. We cannot avoid touching %fs because we use it for kernel > > private data. But if it wasn't for that, we wouldn't be touching > > %fs for regular traps/syscalls/etc either. > > > > Bruce Evans understands this better than I do, I would suggest not making > > this change without talking about it with him first. > > BTW, it's not really a big deal for the UTS to restore %gs > (or probably whatever it ends up being on other archs) before > continuing a thread. I put it to you that %gs should be a way of finding the current KSE mailbox (upcall mailbox) which will NOT CHANGE when a thread is changed in userland. one simply changes the curthread pointer in the KSE (upcall) mailbox, leaving %gs the same. %gs should never change for a single KSE as it goes in and out of the kernel, it must always have the same mailbox. > > -- > Dan Eischen > > _______________________________________________ > 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 Fri Apr 11 00:49:02 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 0ABE437B401 for ; Fri, 11 Apr 2003 00:49:02 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40EC043FA3 for ; Fri, 11 Apr 2003 00:49:01 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h3B7n0l55915 for ; Fri, 11 Apr 2003 03:49:00 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Fri, 11 Apr 2003 03:49:00 -0400 (EDT) From: Jeff Roberson To: freebsd-threads@freebsd.org Message-ID: <20030411034715.T37530-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: KSE signals broken by 1:1 commit. 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, 11 Apr 2003 07:49:02 -0000 So I don't think you are fair enough! I ever posted a message said that jeff's patch had bug, the bug is signal lost, but he obviously didn't fixed it, and you guy allowed him to commit it, please search arch list about 1:1 thread! I don't think delaying some days of libthr change to kernel would hurt anything, I had reported the problem and why did core still allow him to commit? David Xu The problem is a minor race where an exiting thread could have a process wide signal pending when it exits. Hardly a critical issue. Why did we allow any of kern_thread.c to be commited when it obviously doesn't work at all? Cheers, Jeff From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 01:11:41 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 D42F937B401 for ; Fri, 11 Apr 2003 01:11:41 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6330943F3F for ; Fri, 11 Apr 2003 01:11:41 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc52.attbi.com (rwcrmhc52) with ESMTP id <2003041108114005200lhim0e>; Fri, 11 Apr 2003 08:11:40 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA95419; Fri, 11 Apr 2003 01:11:40 -0700 (PDT) Date: Fri, 11 Apr 2003 01:11:38 -0700 (PDT) From: Julian Elischer To: Jeff Roberson In-Reply-To: <20030411034715.T37530-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: KSE signals broken by 1:1 commit. 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, 11 Apr 2003 08:11:42 -0000 On Fri, 11 Apr 2003, Jeff Roberson wrote: > So I don't think you are fair enough! > I ever posted a message said that jeff's patch had bug, > the bug is signal lost, but he obviously didn't fixed it, > and you guy allowed him to commit it, please search arch list > about 1:1 thread! I don't think delaying some days of libthr > change to kernel would hurt anything, I had reported > the problem and why did core still allow him to commit? > > David Xu > > > The problem is a minor race where an exiting thread could have a process > wide signal pending when it exits. Hardly a critical issue. Why did we > allow any of kern_thread.c to be commited when it obviously doesn't work > at all? To allow people to try parts of it that did work. Signals worked well enough to allow people to try out teh concept of upcalls and userland scheduling. We got a lot of feedback and learned a lot. kern_thread.c BTW is full of functions that are not generally called AT ALL for non KSE processes. so in effect it is NOT in general use. (the only parts called in normal use are the KSE and KSEG and thread allocators and destructors.) so the risk in having it committed was very small and gained a lot. Enough of this.. I've wasted the first evening I've had free in a month arguing and that's well and truly too much. I'm goign back to sripping out KSEs and I'll pass a patch around when it's done. It will probably (definitly) have some effect on ule so I'm not going to do anything until you've had time to digest it and we can come to some agreement about it. > > Cheers, > Jeff > > _______________________________________________ > 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 Fri Apr 11 01:53:20 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 4DDF637B401 for ; Fri, 11 Apr 2003 01:53:20 -0700 (PDT) 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 5B7D543F3F for ; Fri, 11 Apr 2003 01:53:17 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (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 HLDQP5A0; Fri, 11 Apr 2003 16:39:40 +0800 Message-ID: <040c01c30008$03590590$f001a8c0@davidw2k> From: "David Xu" To: "Julian Elischer" , "Daniel Eischen" References: Date: Fri, 11 Apr 2003 16:54:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 08:53:20 -0000 ----- Original Message -----=20 From: "Julian Elischer" To: "Daniel Eischen" Cc: "Peter Wemm" ; "David Xu" ; = Sent: Friday, April 11, 2003 2:54 PM Subject: Re: patch for %gs saving=20 >=20 >=20 > On Fri, 11 Apr 2003, Daniel Eischen wrote: >=20 > > On Thu, 10 Apr 2003, Peter Wemm wrote: > >=20 > > > "David Xu" wrote: > > > > Here is the patch for kernel to save %gs, > > > > it works well on my machine. > > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > > Daniel, is this the reason in your libpthread > > > > patch that doesn't use getcontext syscall ? > > >=20 > > > To put some background on the issue, there is a reason why we did = not > > > do this. %gs is not used by the kernel, so it does not normally = need to > > > be saved and restored on every trap into the kernel. Setting a = segment > > > register is Really Slow - measured in hundreds of clock cycles. > > >=20 > > > So, we normally only touch %gs when we context switch to a = different process > > > that may have a different %gs. Or when one of the context = syscalls wants > > > it changed. We cannot avoid touching %fs because we use it for = kernel > > > private data. But if it wasn't for that, we wouldn't be touching > > > %fs for regular traps/syscalls/etc either. > > >=20 > > > Bruce Evans understands this better than I do, I would suggest not = making > > > this change without talking about it with him first. > >=20 > > BTW, it's not really a big deal for the UTS to restore %gs > > (or probably whatever it ends up being on other archs) before > > continuing a thread. >=20 > I put it to you that %gs should be a way of finding the current KSE > mailbox > (upcall mailbox) which will NOT CHANGE when a thread is changed in > userland. one simply changes the curthread pointer in the KSE (upcall) > mailbox, leaving %gs the same. >=20 > %gs should never change for a single KSE as it goes in and out of the > kernel, it must always have the same mailbox. >=20 >=20 Yes, I saw some code in libpthread patch changes %gs, for example thr_switch(), thr_enter_uts(), I think such code=20 needn't change %gs, and I think even %fs, %ds, %es is needn't to be changed, this would speedup context switch. >=20 > >=20 > > --=20 > > Dan Eischen > >=20 > > _______________________________________________ > > 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 Fri Apr 11 02:26:57 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 6B75337B401 for ; Fri, 11 Apr 2003 02:26:57 -0700 (PDT) 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 7230143FB1 for ; Fri, 11 Apr 2003 02:26:55 -0700 (PDT) (envelope-from davidxu@viatech.com.cn) Received: from davidw2k (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 HLDQP51C; Fri, 11 Apr 2003 17:13:20 +0800 Message-ID: <001901c3000c$b72c57d0$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Fri, 11 Apr 2003 17:28:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 09:26:57 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Friday, April 11, 2003 1:55 PM Subject: Re: patch for %gs saving > On Fri, 11 Apr 2003, David Xu wrote: > > Here is the patch for kernel to save %gs, > > it works well on my machine. > > http://people.freebsd.org/~davidxu/i386_gs.diff >=20 > Thanks, I'll give it a go. >=20 > > Daniel, is this the reason in your libpthread > > patch that doesn't use getcontext syscall ? >=20 > No, we already had userland versions of getcontext() > so I simply reused them to avoid the system call. > That's why THR_GETCONTEXT is a macro; it can be > defined to be getcontext() for those archs that > don't have userland versions and want to use the > system call instead. >=20 > Note that we still need userland versions of > _thread_switch() and _thread_enter_uts() anyways, > so writing a userland [gs]etcontext() is probably > pretty simple once you have those. >=20 > Plus, when you get a context in order to make a > context for a new thread, you still can't rely on > %gs because it may be scheduled on another KSE or > the thread could be a scope system thread in which > case it be scheduled in another KSEG. So the current > %gs isn't necessarily correct for a new thread. >=20 > Hmm, this raises a good point. Once you set up a > thread to run a signal handler, the %gs register has > already been set. We have to be sure that the > interrupted context and the thread's new (signal) > context both have the same %gs and that it runs on > the correct KSE. Either that, or we have to be able > to change the contexts to be the correct %gs before > running the thread and invoking the handler. >=20 I think those code shouldn't touch %gs, these includes _thread_switch(), _thread_enter_uts(), they don't know there is a %gs register. Execept kse_entry(), when first time an upcall is made, it sets %gs to its own LDT, I=20 think you have already done this, but _thread_switch(), and _thread_enter_uts() might be change to not touch %gs. > --=20 > Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 05:43:22 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 3421337B401; Fri, 11 Apr 2003 05:43:22 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D10343F93; Fri, 11 Apr 2003 05:43:21 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3BChEBg013986; Fri, 11 Apr 2003 08:43:14 -0400 (EDT) Received: from localhost (eischen@localhost)h3BChDCK013983; Fri, 11 Apr 2003 08:43:13 -0400 (EDT) Date: Fri, 11 Apr 2003 08:43:13 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 12:43:22 -0000 On Thu, 10 Apr 2003, Julian Elischer wrote: > > On Fri, 11 Apr 2003, Daniel Eischen wrote: > > > On Thu, 10 Apr 2003, Peter Wemm wrote: > > > > > "David Xu" wrote: > > > > Here is the patch for kernel to save %gs, > > > > it works well on my machine. > > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > > Daniel, is this the reason in your libpthread > > > > patch that doesn't use getcontext syscall ? > > > > > > To put some background on the issue, there is a reason why we did not > > > do this. %gs is not used by the kernel, so it does not normally need to > > > be saved and restored on every trap into the kernel. Setting a segment > > > register is Really Slow - measured in hundreds of clock cycles. > > > > > > So, we normally only touch %gs when we context switch to a different process > > > that may have a different %gs. Or when one of the context syscalls wants > > > it changed. We cannot avoid touching %fs because we use it for kernel > > > private data. But if it wasn't for that, we wouldn't be touching > > > %fs for regular traps/syscalls/etc either. > > > > > > Bruce Evans understands this better than I do, I would suggest not making > > > this change without talking about it with him first. > > > > BTW, it's not really a big deal for the UTS to restore %gs > > (or probably whatever it ends up being on other archs) before > > continuing a thread. > > I put it to you that %gs should be a way of finding the current KSE > mailbox It is already. > (upcall mailbox) which will NOT CHANGE when a thread is changed in > userland. one simply changes the curthread pointer in the KSE (upcall) > mailbox, leaving %gs the same. > > %gs should never change for a single KSE as it goes in and out of the > kernel, it must always have the same mailbox. The problem is switching a thread _between_ KSEs. If there are multiple KSEs in a KSEG, then threads can be migrated between those KSEs by the UTS. When a thread blocks in the kernel and then completes, there is no guarantee that the completion upcall will occur on the same KSE in which the thread was running when it blocked. Right now, there is one scheduling queue for each KSEG (in the UTS), so there is currently no notion of binding threads to specific KSEs within a KSEG. If we want to bind threads to specific KSEs, then we need some sort of load balancing in the UTS and then still need the ability to migrate threads. If you continue a thread on another KSE, then you have to adjust it's %gs. And this gets a bit more complicated when you think about signal handlers and the fact that %gs is in the interrupted context that gets passed to the signal handler (which the application can use to setcontext() to). -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 05:49:01 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 92E1237B401 for ; Fri, 11 Apr 2003 05:49:01 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA93A43F75 for ; Fri, 11 Apr 2003 05:49:00 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3BCn0Bg014651; Fri, 11 Apr 2003 08:49:00 -0400 (EDT) Received: from localhost (eischen@localhost)h3BCmw7G014647; Fri, 11 Apr 2003 08:48:59 -0400 (EDT) Date: Fri, 11 Apr 2003 08:48:58 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <001901c3000c$b72c57d0$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 12:49:02 -0000 On Fri, 11 Apr 2003, David Xu wrote: > ----- Original Message ----- > From: "Daniel Eischen" > To: "David Xu" > Cc: > Sent: Friday, April 11, 2003 1:55 PM > Subject: Re: patch for %gs saving > > > > On Fri, 11 Apr 2003, David Xu wrote: > > > Here is the patch for kernel to save %gs, > > > it works well on my machine. > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > > Thanks, I'll give it a go. > > > > > Daniel, is this the reason in your libpthread > > > patch that doesn't use getcontext syscall ? > > > > No, we already had userland versions of getcontext() > > so I simply reused them to avoid the system call. > > That's why THR_GETCONTEXT is a macro; it can be > > defined to be getcontext() for those archs that > > don't have userland versions and want to use the > > system call instead. > > > > Note that we still need userland versions of > > _thread_switch() and _thread_enter_uts() anyways, > > so writing a userland [gs]etcontext() is probably > > pretty simple once you have those. > > > > Plus, when you get a context in order to make a > > context for a new thread, you still can't rely on > > %gs because it may be scheduled on another KSE or > > the thread could be a scope system thread in which > > case it be scheduled in another KSEG. So the current > > %gs isn't necessarily correct for a new thread. > > > > Hmm, this raises a good point. Once you set up a > > thread to run a signal handler, the %gs register has > > already been set. We have to be sure that the > > interrupted context and the thread's new (signal) > > context both have the same %gs and that it runs on > > the correct KSE. Either that, or we have to be able > > to change the contexts to be the correct %gs before > > running the thread and invoking the handler. > > > > I think those code shouldn't touch %gs, these includes > _thread_switch(), _thread_enter_uts(), they don't know > there is a %gs register. Execept kse_entry(), when first > time an upcall is made, it sets %gs to its own LDT, I > think you have already done this, but _thread_switch(), > and _thread_enter_uts() might be change to not touch %gs. getcontext() and setcontext() still touch %gs though. If an application uses those functions and they are used in a thread once while it is on one KSE and another time while it is on a different KSE, then %gs gets hosed. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 06:01:09 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 8636637B401; Fri, 11 Apr 2003 06:01:09 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B08FC43F75; Fri, 11 Apr 2003 06:01:08 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3BD12Bg016193; Fri, 11 Apr 2003 09:01:02 -0400 (EDT) Received: from localhost (eischen@localhost)h3BD11Fa016190; Fri, 11 Apr 2003 09:01:01 -0400 (EDT) Date: Fri, 11 Apr 2003 09:01:01 -0400 (EDT) From: Daniel Eischen To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 13:01:10 -0000 On Fri, 11 Apr 2003, Daniel Eischen wrote: > On Thu, 10 Apr 2003, Julian Elischer wrote: > > > > On Fri, 11 Apr 2003, Daniel Eischen wrote: > > > > > On Thu, 10 Apr 2003, Peter Wemm wrote: > > > > > > > "David Xu" wrote: > > > > > Here is the patch for kernel to save %gs, > > > > > it works well on my machine. > > > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > > > Daniel, is this the reason in your libpthread > > > > > patch that doesn't use getcontext syscall ? > > > > > > > > To put some background on the issue, there is a reason why we did not > > > > do this. %gs is not used by the kernel, so it does not normally need to > > > > be saved and restored on every trap into the kernel. Setting a segment > > > > register is Really Slow - measured in hundreds of clock cycles. > > > > > > > > So, we normally only touch %gs when we context switch to a different process > > > > that may have a different %gs. Or when one of the context syscalls wants > > > > it changed. We cannot avoid touching %fs because we use it for kernel > > > > private data. But if it wasn't for that, we wouldn't be touching > > > > %fs for regular traps/syscalls/etc either. > > > > > > > > Bruce Evans understands this better than I do, I would suggest not making > > > > this change without talking about it with him first. > > > > > > BTW, it's not really a big deal for the UTS to restore %gs > > > (or probably whatever it ends up being on other archs) before > > > continuing a thread. > > > > I put it to you that %gs should be a way of finding the current KSE > > mailbox > > It is already. > > > (upcall mailbox) which will NOT CHANGE when a thread is changed in > > userland. one simply changes the curthread pointer in the KSE (upcall) > > mailbox, leaving %gs the same. > > > > %gs should never change for a single KSE as it goes in and out of the > > kernel, it must always have the same mailbox. > > The problem is switching a thread _between_ KSEs. If there are > multiple KSEs in a KSEG, then threads can be migrated between > those KSEs by the UTS. When a thread blocks in the kernel and > then completes, there is no guarantee that the completion upcall > will occur on the same KSE in which the thread was running when > it blocked. Right now, there is one scheduling queue for each > KSEG (in the UTS), so there is currently no notion of binding > threads to specific KSEs within a KSEG. If we want to bind > threads to specific KSEs, then we need some sort of load > balancing in the UTS and then still need the ability to > migrate threads. > > If you continue a thread on another KSE, then you have to adjust > it's %gs. And this gets a bit more complicated when you think > about signal handlers and the fact that %gs is in the interrupted > context that gets passed to the signal handler (which the application > can use to setcontext() to). We'd have to hack __sys_[sg]etcontext() to avoid restoring %gs for a KSE enabled application. This muddies up [gs]et_mcontext() because I think you do want %gs in some instances. Either that, or the UTS will be required to have userland versions of [gs]etcontext() so that %gs (or whatever) is ignored. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 08:32:28 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 CE9E237B401; Fri, 11 Apr 2003 08:32:28 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AE1243FB1; Fri, 11 Apr 2003 08:32:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0023.cvx40-bradley.dialup.earthlink.net ([216.244.42.23] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1940Vu-00002w-00; Fri, 11 Apr 2003 08:32:27 -0700 Message-ID: <3E96DFB7.9E5AC29A@mindspring.com> Date: Fri, 11 Apr 2003 08:31:03 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Xu References: <20030411053722.782152A7EA@canning.wemm.org> <012401c2ffef$e50657e0$f001a8c0@davidw2k> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4aede999b2b29e7f2ea43533071cb1d8e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 15:32:29 -0000 David Xu wrote: > Yes, I know loading a descriptor is slow, but in real world, such optimization > will be lost in real work noise. And setcontext syscall is broken by this > optimization, userland will fail to set his context in atomic operation, > set pcb->gs = userland_gs does not work, so the cost is obviously, I can optimize > my patch to only save and restore %gs at trap and interrupt time, when entering > kernel, I can always zero %gs because kernel does not use it, I think this can > reduce clock cycles at context switch, this might be better than current code > which loading %gs at every context switch. If it's a threaded program, you are probably going to have to reload the %gs on a contex switch. If it's not, you can lazy bind it, meaning that you only reload it when you go from one threaded process to a different threaded process, and leave it alone otherwise (check its value where you would reload it for a threaded process, in case some other unthreaded process has decided to use it; boils down to a compare-if-different-reload, in both cases). In the UTS, you can also lazy bind the reload, since if you go to sleep and end up rescheduling the thread, it will have the same value as previously. With the kernel support, you will be safe to do this. The one thing that this could result in is, if the process is in the UTS, and another process has changed %gs, such that when you get the quantum from the kernel, it would reload %gs, and then return to user space, and the UTS would again reload %gs to then schedule another user space thread. The only way I can see to avoid this latency would be for the kernel to know the process is in the UTS, before the place where the UTS would reload %gs. If you could know this, then you could avoid the dual reload, by having the kernel *not* reload %gs, even if it's changed, in that case. Thus the UTS becomes compare-if-different-reload as well. You could probably do this with a flag in a mailbox that is associated with the UTS. The "extra" cost is a compare in both places, which (probably) avoids a statistically significant number of %gs reloads. -- Terry From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 08:52:59 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 BFB0437B401 for ; Fri, 11 Apr 2003 08:52:59 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E0C043F3F for ; Fri, 11 Apr 2003 08:52:59 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0023.cvx40-bradley.dialup.earthlink.net ([216.244.42.23] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1940pk-0004om-00; Fri, 11 Apr 2003 08:52:56 -0700 Message-ID: <3E96E486.9B6C5832@mindspring.com> Date: Fri, 11 Apr 2003 08:51:34 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Roberson References: <20030411034715.T37530-100000@mail.chesapeake.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42cf4e1d083019246e6438d7c2314649fa2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: freebsd-threads@freebsd.org Subject: Re: KSE signals broken by 1:1 commit. 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, 11 Apr 2003 15:53:00 -0000 Jeff Roberson wrote: > Why did we allow any of kern_thread.c to be commited when it > obviously doesn't work at all? Not that I want this thread to continue, but I believe the reason was that committing it didn't obstruct other work. -- Terry From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 10: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 B1A1B37B401; Fri, 11 Apr 2003 10:05:42 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00E6743FA3; Fri, 11 Apr 2003 10:05:42 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3BH5fBg019785; Fri, 11 Apr 2003 13:05:41 -0400 (EDT) Received: from localhost (eischen@localhost)h3BH5eSm019781; Fri, 11 Apr 2003 13:05:40 -0400 (EDT) Date: Fri, 11 Apr 2003 13:05:40 -0400 (EDT) From: Daniel Eischen To: freebsd-threads@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: davidxu@freebsd.org Subject: New libpthread patch available. 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, 11 Apr 2003 17:05:43 -0000 David, I fixed a couple of bugs and put another patch set up at the usual place: http://people.freebsd.org/~deischen/libpthread.diffs This seems to pass all but 10 or so of the 110 ACE tests. I'll do some more testing with this and libc_r and post those results later. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 11:11: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 409F337B401; Fri, 11 Apr 2003 11:11:17 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65C5143F3F; Fri, 11 Apr 2003 11:11:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <200304111811140020070oc3e>; Fri, 11 Apr 2003 18:11:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA99100; Fri, 11 Apr 2003 11:11:13 -0700 (PDT) Date: Fri, 11 Apr 2003 11:11:11 -0700 (PDT) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 18:11:17 -0000 On Fri, 11 Apr 2003, Daniel Eischen wrote: > On Thu, 10 Apr 2003, Julian Elischer wrote: > > > > On Fri, 11 Apr 2003, Daniel Eischen wrote: > > > > > On Thu, 10 Apr 2003, Peter Wemm wrote: > > > > > > > "David Xu" wrote: > > > > > Here is the patch for kernel to save %gs, > > > > > it works well on my machine. > > > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > > > Daniel, is this the reason in your libpthread > > > > > patch that doesn't use getcontext syscall ? > > > > > > > > To put some background on the issue, there is a reason why we did not > > > > do this. %gs is not used by the kernel, so it does not normally need to > > > > be saved and restored on every trap into the kernel. Setting a segment > > > > register is Really Slow - measured in hundreds of clock cycles. > > > > > > > > So, we normally only touch %gs when we context switch to a different process > > > > that may have a different %gs. Or when one of the context syscalls wants > > > > it changed. We cannot avoid touching %fs because we use it for kernel > > > > private data. But if it wasn't for that, we wouldn't be touching > > > > %fs for regular traps/syscalls/etc either. > > > > > > > > Bruce Evans understands this better than I do, I would suggest not making > > > > this change without talking about it with him first. > > > > > > BTW, it's not really a big deal for the UTS to restore %gs > > > (or probably whatever it ends up being on other archs) before > > > continuing a thread. > > > > I put it to you that %gs should be a way of finding the current KSE > > mailbox > > It is already. > > > (upcall mailbox) which will NOT CHANGE when a thread is changed in > > userland. one simply changes the curthread pointer in the KSE (upcall) > > mailbox, leaving %gs the same. > > > > %gs should never change for a single KSE as it goes in and out of the > > kernel, it must always have the same mailbox. > > The problem is switching a thread _between_ KSEs. If there are > multiple KSEs in a KSEG, then threads can be migrated between > those KSEs by the UTS. When a thread blocks in the kernel and > then completes, there is no guarantee that the completion upcall > will occur on the same KSE in which the thread was running when > it blocked. Right now, there is one scheduling queue for each > KSEG (in the UTS), so there is currently no notion of binding > threads to specific KSEs within a KSEG. If we want to bind > threads to specific KSEs, then we need some sort of load > balancing in the UTS and then still need the ability to > migrate threads. > > If you continue a thread on another KSE, then you have to adjust > it's %gs. And this gets a bit more complicated when you think > about signal handlers and the fact that %gs is in the interrupted > context that gets passed to the signal handler (which the application > can use to setcontext() to). no, you shouldn't touch %gs the KSE you are shifting to already has the right value in %gs don't overwrite it.. (don't save %gs, don't reload it) > > -- > Dan Eischen > > From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 11:12: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 C926F37B401 for ; Fri, 11 Apr 2003 11:12:14 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5280643F75 for ; Fri, 11 Apr 2003 11:12:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc53.attbi.com (rwcrmhc53) with ESMTP id <2003041118121305300dmt52e>; Fri, 11 Apr 2003 18:12:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA99104; Fri, 11 Apr 2003 11:12:12 -0700 (PDT) Date: Fri, 11 Apr 2003 11:12:12 -0700 (PDT) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 18:12:15 -0000 On Fri, 11 Apr 2003, Daniel Eischen wrote: > On Fri, 11 Apr 2003, David Xu wrote: > > ----- Original Message ----- > > From: "Daniel Eischen" > > To: "David Xu" > > Cc: > > Sent: Friday, April 11, 2003 1:55 PM > > Subject: Re: patch for %gs saving > > > > > > > On Fri, 11 Apr 2003, David Xu wrote: > > > > Here is the patch for kernel to save %gs, > > > > it works well on my machine. > > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > > > > Thanks, I'll give it a go. > > > > > > > Daniel, is this the reason in your libpthread > > > > patch that doesn't use getcontext syscall ? > > > > > > No, we already had userland versions of getcontext() > > > so I simply reused them to avoid the system call. > > > That's why THR_GETCONTEXT is a macro; it can be > > > defined to be getcontext() for those archs that > > > don't have userland versions and want to use the > > > system call instead. > > > > > > Note that we still need userland versions of > > > _thread_switch() and _thread_enter_uts() anyways, > > > so writing a userland [gs]etcontext() is probably > > > pretty simple once you have those. > > > > > > Plus, when you get a context in order to make a > > > context for a new thread, you still can't rely on > > > %gs because it may be scheduled on another KSE or > > > the thread could be a scope system thread in which > > > case it be scheduled in another KSEG. So the current > > > %gs isn't necessarily correct for a new thread. > > > > > > Hmm, this raises a good point. Once you set up a > > > thread to run a signal handler, the %gs register has > > > already been set. We have to be sure that the > > > interrupted context and the thread's new (signal) > > > context both have the same %gs and that it runs on > > > the correct KSE. Either that, or we have to be able > > > to change the contexts to be the correct %gs before > > > running the thread and invoking the handler. > > > > > > > I think those code shouldn't touch %gs, these includes > > _thread_switch(), _thread_enter_uts(), they don't know > > there is a %gs register. Execept kse_entry(), when first > > time an upcall is made, it sets %gs to its own LDT, I > > think you have already done this, but _thread_switch(), > > and _thread_enter_uts() might be change to not touch %gs. > > getcontext() and setcontext() still touch %gs though. > If an application uses those functions and they are > used in a thread once while it is on one KSE and > another time while it is on a different KSE, then > %gs gets hosed. they should not touch %gs > > -- > Dan Eischen > > _______________________________________________ > 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 Fri Apr 11 12:10:06 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 04C4737B401; Fri, 11 Apr 2003 12:10:06 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CE0B43F93; Fri, 11 Apr 2003 12:10:05 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 68C322A7EA; Fri, 11 Apr 2003 12:10:05 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "David Xu" In-Reply-To: <012401c2ffef$e50657e0$f001a8c0@davidw2k> Date: Fri, 11 Apr 2003 12:10:05 -0700 From: Peter Wemm Message-Id: <20030411191005.68C322A7EA@canning.wemm.org> cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 19:10:06 -0000 "David Xu" wrote: > > ----- Original Message -----=20 > From: "Peter Wemm" > To: "David Xu" > Cc: > Sent: Friday, April 11, 2003 1:37 PM > Subject: Re: patch for %gs saving=20 > > > > "David Xu" wrote: > > > Here is the patch for kernel to save %gs, > > > it works well on my machine. > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > Daniel, is this the reason in your libpthread > > > patch that doesn't use getcontext syscall ? > >=20 > > To put some background on the issue, there is a reason why we did not > > do this. %gs is not used by the kernel, so it does not normally need = > to > > be saved and restored on every trap into the kernel. Setting a = > segment > > register is Really Slow - measured in hundreds of clock cycles. > >=20 > > So, we normally only touch %gs when we context switch to a different = > process > > that may have a different %gs. Or when one of the context syscalls = > wants > > it changed. We cannot avoid touching %fs because we use it for kernel > > private data. But if it wasn't for that, we wouldn't be touching > > %fs for regular traps/syscalls/etc either. > >=20 > > Bruce Evans understands this better than I do, I would suggest not = > making > > this change without talking about it with him first. > >=20 > > Yes, I know loading a descriptor is slow, but in real world, such = > optimization > will be lost in real work noise. And setcontext syscall is broken by = > this > optimization, userland will fail to set his context in atomic operation, > set pcb->gs =3D userland_gs does not work, so the cost is obviously, I = > can optimize > my patch to only save and restore %gs at trap and interrupt time, when = > entering > kernel, I can always zero %gs because kernel does not use it, I think = > this can > reduce clock cycles at context switch, this might be better than current = > code which > loading %gs at every context switch. Currently we only change %gs when switching one entire process to another seperate process. Your patch changes it so that it changes %gs on every single fault/trap/syscall/etc. I regularly see process traces where the ratio of syscalls to context switches is over 1000 to 1. ie: your patch would increase the cost of the %gs activity over a thousand times. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 16:29:56 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 A7A6837B401; Fri, 11 Apr 2003 16:29:56 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C81CB43F75; Fri, 11 Apr 2003 16:29:55 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3BNTsBg013765; Fri, 11 Apr 2003 19:29:54 -0400 (EDT) Received: from localhost (eischen@localhost)h3BNTs2X013762; Fri, 11 Apr 2003 19:29:54 -0400 (EDT) Date: Fri, 11 Apr 2003 19:29:54 -0400 (EDT) From: Daniel Eischen To: freebsd-threads@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: davidxu@freebsd.org Subject: Re: New libpthread patch available. 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, 11 Apr 2003 23:29:57 -0000 On Fri, 11 Apr 2003, Daniel Eischen wrote: > David, > > I fixed a couple of bugs and put another patch set up at the usual place: > > http://people.freebsd.org/~deischen/libpthread.diffs > > This seems to pass all but 10 or so of the 110 ACE tests. I'll do some > more testing with this and libc_r and post those results later. Here's the rundown of the tests that don't pass: libkse libc_r ACE 5.3.1 Test Pass? Pass? ------------------------------------------------ Cached_Conn_Test No No Conn_Test No Yes MT_Reactor_Timer_Test No Yes Malloc_Test No No Proactor_Test No No Proactor_Timer_Test No No Process_Manager_Test No Yes Process_Strategy_Test No Yes Sigset_Ops_Test No No Thread_Pool_Test No Yes So we're only 5 short of catching up to where libc_r is. Once signals get fixed, that my solve some of the remaining problems (Jeff, Julian???). The full results of the 110 ACE tests is at: http://people.freebsd.org/~deischen/kse/ACE_test_results.txt -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 16:41:38 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 F02A937B404 for ; Fri, 11 Apr 2003 16:41:38 -0700 (PDT) Received: from h00609772adf0.ne.client2.attbi.com (h00609772adf0.ne.client2.attbi.com [24.61.43.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0472143F75 for ; Fri, 11 Apr 2003 16:41:38 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from h00609772adf0.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1])h3BNffcJ051069; Fri, 11 Apr 2003 19:41:41 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)h3BNffl5051068; Fri, 11 Apr 2003 19:41:41 -0400 (EDT) Date: Fri, 11 Apr 2003 19:41:40 -0400 From: Craig Rodrigues To: Daniel Eischen Message-ID: <20030411234140.GA51044@attbi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: freebsd-threads@freebsd.org Subject: Re: New libpthread patch available. 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, 11 Apr 2003 23:41:39 -0000 On Fri, Apr 11, 2003 at 07:29:54PM -0400, Daniel Eischen wrote: > > libkse libc_r > ACE 5.3.1 Test Pass? Pass? > ------------------------------------------------ > Cached_Conn_Test No No > Conn_Test No Yes > MT_Reactor_Timer_Test No Yes > Malloc_Test No No > Proactor_Test No No > Proactor_Timer_Test No No > Process_Manager_Test No Yes > Process_Strategy_Test No Yes > Sigset_Ops_Test No No > Thread_Pool_Test No Yes > Hi, Would you be interested in using the ACE autobuild perl scripts to run the ACE tests? The results of the tests are formatted in a nice HTML format which you can push to a web page. For example, the build output of my build of ACE+TAO is published here: http://www.dist-systems.bbn.com/projects/AIRES/UAV/scoreboard/main/ If I see your build output, I may be able to help isoloate some problems. The Proactor stuff depends on POSIX AIO + threads, so looking too closely at that for KSE may be a waste of time, unless you want to look at AIO also. Sigset depends on proper signals support. The Thread tests are worth paying attention to. The other thing to keep in mind is that some of the ACE tests are very convoluted and busted in subtle ways. If you are interested using the autobuild scripts to publish your ACE build output, I can help you with that off the list. -- Craig Rodrigues http://home.attbi.com/~rodrigc rodrigc@attbi.com From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 16:51:51 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 9B04637B401 for ; Fri, 11 Apr 2003 16:51:51 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8106C43F93 for ; Fri, 11 Apr 2003 16:51:50 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3BNpnBg016358; Fri, 11 Apr 2003 19:51:49 -0400 (EDT) Received: from localhost (eischen@localhost)h3BNpn4x016354; Fri, 11 Apr 2003 19:51:49 -0400 (EDT) Date: Fri, 11 Apr 2003 19:51:49 -0400 (EDT) From: Daniel Eischen To: Craig Rodrigues In-Reply-To: <20030411234140.GA51044@attbi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: New libpthread patch available. 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, 11 Apr 2003 23:51:52 -0000 On Fri, 11 Apr 2003, Craig Rodrigues wrote: > On Fri, Apr 11, 2003 at 07:29:54PM -0400, Daniel Eischen wrote: > > > > libkse libc_r > > ACE 5.3.1 Test Pass? Pass? > > ------------------------------------------------ > > Cached_Conn_Test No No > > Conn_Test No Yes > > MT_Reactor_Timer_Test No Yes > > Malloc_Test No No > > Proactor_Test No No > > Proactor_Timer_Test No No > > Process_Manager_Test No Yes > > Process_Strategy_Test No Yes > > Sigset_Ops_Test No No > > Thread_Pool_Test No Yes > > > > > Hi, > > Would you be interested in using the ACE autobuild perl scripts > to run the ACE tests? The results of the tests are formatted > in a nice HTML format which you can push to a web page. Sure, I guess so. Does it come with ACE? > For example, the build output of my build of ACE+TAO is published here: > > http://www.dist-systems.bbn.com/projects/AIRES/UAV/scoreboard/main/ > > If I see your build output, I may be able to help isoloate some > problems. The Proactor stuff depends on POSIX AIO + threads, so looking > too closely at that for KSE may be a waste of time, unless you want to > look at AIO also. Sigset depends on proper signals support. Yeah, I know sigset is broken; our sig*set macros don't check for invalid signals. I don't want to mess around with AIO either. > The Thread tests are worth paying attention to. The other thing > to keep in mind is that some of the ACE tests are very convoluted > and busted in subtle ways. Yeah, I remember with earlier versions of ACE, sometimes a test would fail and other times it would pass. > If you are interested using the autobuild scripts to publish your > ACE build output, I can help you with that off the list. I have all the output; it just not HTML'ized. Send me what I need to know off-line. I'll see if I can get it working. You can run the tests yourself too, by applying the patch :-) -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 17:00:30 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 A1BF037B401; Fri, 11 Apr 2003 17:00:30 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE9EC43F85; Fri, 11 Apr 2003 17:00:25 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h3C00OUp076117; Fri, 11 Apr 2003 17:00:25 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <002501c30087$26c203e0$0701a8c0@tiger> From: "David Xu" To: "Peter Wemm" References: <20030411191005.68C322A7EA@canning.wemm.org> Date: Sat, 12 Apr 2003 08:04:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 00:00:30 -0000 ----- Original Message -----=20 From: "Peter Wemm" To: "David Xu" Cc: Sent: Saturday, April 12, 2003 3:10 AM Subject: Re: patch for %gs saving=20 > "David Xu" wrote: > >=20 > > ----- Original Message -----=3D20 > > From: "Peter Wemm" > > To: "David Xu" > > Cc: > > Sent: Friday, April 11, 2003 1:37 PM > > Subject: Re: patch for %gs saving=3D20 > >=20 > >=20 > > > "David Xu" wrote: > > > > Here is the patch for kernel to save %gs, > > > > it works well on my machine. > > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > > Daniel, is this the reason in your libpthread > > > > patch that doesn't use getcontext syscall ? > > >=3D20 > > > To put some background on the issue, there is a reason why we did = not > > > do this. %gs is not used by the kernel, so it does not normally = need =3D > > to > > > be saved and restored on every trap into the kernel. Setting a = =3D > > segment > > > register is Really Slow - measured in hundreds of clock cycles. > > >=3D20 > > > So, we normally only touch %gs when we context switch to a = different =3D > > process > > > that may have a different %gs. Or when one of the context = syscalls =3D > > wants > > > it changed. We cannot avoid touching %fs because we use it for = kernel > > > private data. But if it wasn't for that, we wouldn't be touching > > > %fs for regular traps/syscalls/etc either. > > >=3D20 > > > Bruce Evans understands this better than I do, I would suggest not = =3D > > making > > > this change without talking about it with him first. > > >=3D20 > >=20 > > Yes, I know loading a descriptor is slow, but in real world, such = =3D > > optimization > > will be lost in real work noise. And setcontext syscall is broken by = =3D > > this > > optimization, userland will fail to set his context in atomic = operation, > > set pcb->gs =3D3D userland_gs does not work, so the cost is = obviously, I =3D > > can optimize > > my patch to only save and restore %gs at trap and interrupt time, = when =3D > > entering > > kernel, I can always zero %gs because kernel does not use it, I = think =3D > > this can > > reduce clock cycles at context switch, this might be better than = current =3D > > code which > > loading %gs at every context switch. >=20 > Currently we only change %gs when switching one entire process to = another > seperate process. Your patch changes it so that it changes %gs on = every > single fault/trap/syscall/etc. I regularly see process traces where > the ratio of syscalls to context switches is over 1000 to 1. ie: your > patch would increase the cost of the %gs activity over a thousand = times. >=20 Yes, you are right, I wouldn't change kernel code to save and restore = %gs at every trap/interrupt, I have measured it, I won't do. however, these is couple of bugs: 1. set_mcontext: does not work for %gs if the thread calling set_mcontext is the curthread. 2. set_user_ldt_rv: it does not reload %gs when user LDT might be changed. 3. cpu_switch_load_gs: in trap.c, if cpu_switch_load_gs is failed, trap.c will = psignal(SIGSEGV), however when cpu_switch_load_gs is failed, it is under sched_lock = held, so PROC_LOCK(p) generates LOR and dead lock is possible. 4. other code need to reload %gs set_mcontext and set_user_ldt_rv etcs should be hacked to reloaded %gs, these are costs because of %gs not saved by kernel. > Cheers, > -Peter > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 17:05:59 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 C4B4137B401 for ; Fri, 11 Apr 2003 17:05:59 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7FDA43FA3 for ; Fri, 11 Apr 2003 17:05:58 -0700 (PDT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h3C06GYX084344; Fri, 11 Apr 2003 20:06:16 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost)h3C06Ftt084341; Fri, 11 Apr 2003 20:06:15 -0400 (EDT) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Fri, 11 Apr 2003 20:06:14 -0400 (EDT) From: "Andrew R. Reiter" To: Craig Rodrigues In-Reply-To: <20030411234140.GA51044@attbi.com> Message-ID: <20030411200412.S65977@fledge.watson.org> References: <20030411234140.GA51044@attbi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen cc: freebsd-threads@freebsd.org Subject: Re: New libpthread patch available. 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, 12 Apr 2003 00:06:00 -0000 On Fri, 11 Apr 2003, Craig Rodrigues wrote: :On Fri, Apr 11, 2003 at 07:29:54PM -0400, Daniel Eischen wrote: :> :> libkse libc_r :> ACE 5.3.1 Test Pass? Pass? :> ------------------------------------------------ :> Cached_Conn_Test No No :> Conn_Test No Yes :> MT_Reactor_Timer_Test No Yes :> Malloc_Test No No :> Proactor_Test No No :> Proactor_Timer_Test No No :> Process_Manager_Test No Yes :> Process_Strategy_Test No Yes :> Sigset_Ops_Test No No :> Thread_Pool_Test No Yes :> : : :Hi, : :Would you be interested in using the ACE autobuild perl scripts :to run the ACE tests? The results of the tests are formatted :in a nice HTML format which you can push to a web page. Sorry to get alittle more off-topic than the original email, but how feasible is it to tie something like that into tinderbox so that if there was a checkin to any of the libc_r etc code, we could do the ACE tests? Sounds like the autobuild stuff would help with that? Sorry if this is a bit more off topic than people would like. Cheers, Andrew : :For example, the build output of my build of ACE+TAO is published here: : :http://www.dist-systems.bbn.com/projects/AIRES/UAV/scoreboard/main/ : :If I see your build output, I may be able to help isoloate some :problems. The Proactor stuff depends on POSIX AIO + threads, so looking :too closely at that for KSE may be a waste of time, unless you want to :look at AIO also. Sigset depends on proper signals support. : :The Thread tests are worth paying attention to. The other thing :to keep in mind is that some of the ACE tests are very convoluted :and busted in subtle ways. : :If you are interested using the autobuild scripts to publish your :ACE build output, I can help you with that off the list. :-- :Craig Rodrigues :http://home.attbi.com/~rodrigc :rodrigc@attbi.com :_______________________________________________ :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" : -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 17:06:49 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 D99A437B401; Fri, 11 Apr 2003 17:06:49 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC8743FAF; Fri, 11 Apr 2003 17:06:49 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h3C06mUp081774; Fri, 11 Apr 2003 17:06:48 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <002b01c30088$0b7d9e40$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" , References: Date: Sat, 12 Apr 2003 08:11:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: Re: New libpthread patch available. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 00:06:50 -0000 Thank you, I will test it. My i386_gs.diff patch needn't be applied now, because I have hacked = vm_machdep.c to load a correct %gs for upcall thread. However %gs is not reloaded in = set_context syscall if someone want to reload it as well, I think we needn't it, only need = to keep an eye on it if someone want to hack it. David ----- Original Message -----=20 From: "Daniel Eischen" To: Cc: Sent: Saturday, April 12, 2003 1:05 AM Subject: New libpthread patch available. > David, >=20 > I fixed a couple of bugs and put another patch set up at the usual = place: >=20 > http://people.freebsd.org/~deischen/libpthread.diffs >=20 > This seems to pass all but 10 or so of the 110 ACE tests. I'll do = some > more testing with this and libc_r and post those results later. >=20 > --=20 > Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Fri Apr 11 18:17:49 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 E3F5037B401 for ; Fri, 11 Apr 2003 18:17:48 -0700 (PDT) Received: from h00609772adf0.ne.client2.attbi.com (h00609772adf0.ne.client2.attbi.com [24.61.43.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBDFC43F93 for ; Fri, 11 Apr 2003 18:17:47 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from h00609772adf0.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1])h3C1HpcJ051456; Fri, 11 Apr 2003 21:17:51 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)h3C1Houc051455; Fri, 11 Apr 2003 21:17:50 -0400 (EDT) Date: Fri, 11 Apr 2003 21:17:49 -0400 From: Craig Rodrigues To: "Andrew R. Reiter" Message-ID: <20030412011749.GA51441@attbi.com> References: <20030411234140.GA51044@attbi.com> <20030411200412.S65977@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20030411200412.S65977@fledge.watson.org> User-Agent: Mutt/1.4i cc: freebsd-threads@freebsd.org Subject: Re: New libpthread patch available. 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, 12 Apr 2003 01:17:49 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Apr 11, 2003 at 08:06:14PM -0400, Andrew R. Reiter wrote: > Sorry to get alittle more off-topic than the original email, but how > feasible is it to tie something like that into tinderbox so that if there > was a checkin to any of the libc_r etc code, we could do the ACE tests? > Sounds like the autobuild stuff would help with that? > > Sorry if this is a bit more off topic than people would like. Well, since this is of interest to more than one person, let me post the instructions to the list. I am not familiar enough with the Mozilla project's tinderbox code to say if such an integration is feasible, but it is certainly an intriguing idea. ACE AUTOBUILD INSTRUCTIONS ========================== (0) Check out the autobuild scripts from CVS. cvs -d :pserver:anonymous@anoncvs.ociweb.com:/cvs login (hit enter for password) cvs -d :pserver:anonymous@anoncvs.ociweb.com:/cvs co autobuild (1) mkdir /tmp/ace_build_logs (2) Take the attached FreeBSD.tests.xml file. - customize the ACE_ROOT and root variables in the XML file to reflect where the ACE_wrappers directory is on your system (3) perl autobuild.pl FreeBSD.tests.xml The HTML formatted output should be in /tmp/ace_build_logs -- Craig Rodrigues http://home.attbi.com/~rodrigc rodrigc@attbi.com --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="FreeBSD.tests.xml" --huq684BweRXVnRxX--