From owner-freebsd-arch Sun Nov 19 1:32:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id D352737B479 for ; Sun, 19 Nov 2000 01:32:15 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAJ9WBJ14810 for ; Sun, 19 Nov 2000 11:32:12 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011190932.eAJ9WBJ14810@gratis.grondar.za> To: arch@freebsd.org Subject: "monotonic" counter commit candidate. Reviews, please. Date: Sun, 19 Nov 2000 11:32:02 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I have incorporated a whole bunch more of ideas and concerns from John Baldein and Bruce Evans. I reckon this is now about ready to go in. Comments/reviews please? (Please - If you have objections, and you want me to take them seriously, do some homework and provide me with an alternative (or at least a suggestion for a fix or improvement). If there is no supplied solution or considered suggestion, I find it very difficult to take your objection seriously.) (Please Please - no more arguing about the @#$%ing name, unless you have a genuine concern there. That dead horse is well buried). M Index: sys/systm.h =================================================================== RCS file: /home/ncvs/src/sys/sys/systm.h,v retrieving revision 1.127 diff -u -d -r1.127 systm.h --- sys/systm.h 2000/11/15 22:39:35 1.127 +++ sys/systm.h 2000/11/18 21:31:38 @@ -44,6 +44,7 @@ #include #include +#include #include extern int securelevel; /* system security level (see init(8)) */ Index: alpha/include/systm.h =================================================================== RCS file: systm.h diff -N systm.h --- /dev/null Sun Nov 19 11:09:56 2000 +++ systm.h Sat Nov 18 23:32:02 2000 @@ -0,0 +1,46 @@ +/*- + * Copyright (c) 1993 The Regents of the University of California. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/* + * Functions to provide access to functions that are present in all + * architectures, but machine dependant. + */ + +#ifndef _MACHINE_SYSTM_H_ +#define _MACHINE_SYSTM_H_ + +/* + * Standardised jiffy counter interface + */ +static __inline u_int64_t +get_cyclecount(void) +{ + return alpha_rpcc(); +} + +#endif /* !_MACHINE_SYSTM_H_ */ Index: i386/include/cpufunc.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/cpufunc.h,v retrieving revision 1.99 diff -u -d -r1.99 cpufunc.h --- i386/include/cpufunc.h 2000/10/12 17:05:33 1.99 +++ i386/include/cpufunc.h 2000/11/18 21:29:08 @@ -397,7 +397,7 @@ { u_int64_t rv; - __asm __volatile(".byte 0x0f, 0x31" : "=A" (rv)); + __asm __volatile("rdtsc" : "=A" (rv)); return (rv); } @@ -416,7 +416,7 @@ static __inline void wrmsr(u_int msr, u_int64_t newval) { - __asm __volatile(".byte 0x0f, 0x30" : : "A" (newval), "c" (msr)); + __asm __volatile("wrmsr" : : "A" (newval), "c" (msr)); } static __inline u_int Index: i386/include/systm.h =================================================================== RCS file: systm.h diff -N systm.h --- /dev/null Sun Nov 19 11:09:56 2000 +++ systm.h Sun Nov 19 09:47:44 2000 @@ -0,0 +1,60 @@ +/*- + * Copyright (c) 1993 The Regents of the University of California. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/* + * Functions to provide access to functions that are present in all + * architectures, but machine dependant. + */ + +#ifndef _MACHINE_SYSTM_H_ +#define _MACHINE_SYSTM_H_ + +#if defined(I386_CPU) || defined(I486_CPU) +#include +#include +#include +#endif + +/* + * Standardised jiffy counter interface + */ +static __inline u_int64_t +get_cyclecount(void) +{ +#if defined(I386_CPU) || defined(I486_CPU) + struct timespec tv; + + if (!(cpu_feature & CPUID_TSC)) { + nanotime(&tv); + return (u_int64_t)tv.tv_sec*1000000000L + tv.tv_nsec; + } +#endif + return rdtsc(); +} + +#endif /* !_MACHINE_SYSTM_H_ */ Index: ia64/include/systm.h =================================================================== RCS file: systm.h diff -N systm.h --- /dev/null Sun Nov 19 11:09:56 2000 +++ systm.h Sat Nov 18 23:32:22 2000 @@ -0,0 +1,46 @@ +/*- + * Copyright (c) 1993 The Regents of the University of California. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/* + * Functions to provide access to functions that are present in all + * architectures, but machine dependant. + */ + +#ifndef _MACHINE_SYSTM_H_ +#define _MACHINE_SYSTM_H_ + +/* + * Standardised jiffy counter interface + */ +static __inline u_int64_t +get_cyclecount(void) +{ + return ia64_get_itc(); +} + +#endif /* !_MACHINE_SYSTM_H_ */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 1:57:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id B513437B479 for ; Sun, 19 Nov 2000 01:57:13 -0800 (PST) Received: from victoria-088.budapest.interware.hu ([195.70.63.88] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13xRDf-0005nH-00; Sun, 19 Nov 2000 10:57:08 +0100 Message-ID: <3A17A3F1.B9E6A109@elischer.org> Date: Sun, 19 Nov 2000 01:57:05 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Mark Murray Cc: arch@freebsd.org Subject: Re: "monotonic" counter commit candidate. Reviews, please. References: <200011190932.eAJ9WBJ14810@gratis.grondar.za> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > Hi > > I have incorporated a whole bunch more of ideas and concerns from John > Baldein and Bruce Evans. > > I reckon this is now about ready to go in. > > Comments/reviews please? > + * Copyright (c) 1993 The Regents of the University of California. > + * All rights reserved. > + * > Why are you adding a copyright (1993?) by UCB? Considereing that you don't have any affiliation with them, and you can't assign copyright to someone without their knowledge. I suggest changing it to Freebsd inc. Also I'm getting more and more worried about all this stuff that is becoming more or less 'required' in a kernel. I'd like to see all this entropy stuff more 'rip-outable' than it is. The smallest kernel you can actually make is getting HUGE. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 2:10:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id C011737B479 for ; Sun, 19 Nov 2000 02:10:45 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAJAASJ14890; Sun, 19 Nov 2000 12:10:28 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011191010.eAJAASJ14890@gratis.grondar.za> To: Julian Elischer Cc: arch@freebsd.org Subject: Re: "monotonic" counter commit candidate. Reviews, please. References: <3A17A3F1.B9E6A109@elischer.org> In-Reply-To: <3A17A3F1.B9E6A109@elischer.org> ; from Julian Elischer "Sun, 19 Nov 2000 01:57:05 PST." Date: Sun, 19 Nov 2000 12:10:18 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Why are you adding a copyright (1993?) by UCB? Considereing that you > don't have > any affiliation with them, and you can't assign copyright to someone > without their > knowledge. I suggest changing it to Freebsd inc. Will do. > I'd like to see all this entropy stuff more 'rip-outable' than it is. > The smallest kernel you can actually make is getting HUGE. Have you looked at the function? For anything other than i386/i486 it is one instruction. I was very careful to make /dev/random rip-outable, and this will make /dev/random smaller and faster. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 6:13: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7CCDB37B479 for ; Sun, 19 Nov 2000 06:12:58 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id BAA31678; Mon, 20 Nov 2000 01:12:29 +1100 Date: Mon, 20 Nov 2000 01:12:28 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. In-Reply-To: <200011182252.eAIMqPJ13415@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 19 Nov 2000, Mark Murray wrote: > > > That function is kinda bloated; all I need is rdtsc() and its equivalents. > > > > I'm not sure about that. There are many interesting machine-dependent > > counters. E.g., the counter for the number of instructions executed > > increases at a similar rate to the TSC but is more random. > > I'm not looking for random. I'm looking for a fast counter. You seem to want more than a fast counter. The following implements a fast counter: --- u_int fast_counter; ++fast_counter; --- I will be away for a week and don't have time to reply any more to this thread. BTW, direct mail to you from me has been bouncing for a couple of months. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 6:54:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id CB62D37B479 for ; Sun, 19 Nov 2000 06:54:49 -0800 (PST) Received: from aslan (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id eAJEsO432829; Sun, 19 Nov 2000 07:54:24 -0700 (MST) (envelope-from gibbs@aslan.scsiguy.com) Message-Id: <200011191454.eAJEsO432829@aslan.scsiguy.com> To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: "monotonic" counter commit candidate. Reviews, please. In-Reply-To: Your message of "Sun, 19 Nov 2000 11:32:02 +0200." <200011190932.eAJ9WBJ14810@gratis.grondar.za> Date: Sun, 19 Nov 2000 07:54:24 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Hi > >I have incorporated a whole bunch more of ideas and concerns from John >Baldein and Bruce Evans. Is rdtsc defined in the i386/i486 only case? -- Jusitn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 8:34:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 866A237B479 for ; Sun, 19 Nov 2000 08:34:42 -0800 (PST) Received: from dragon.nuxi.com (root@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id IAA13537; Sun, 19 Nov 2000 08:34:40 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id eAJGYcD39657; Sun, 19 Nov 2000 08:34:38 -0800 (PST) (envelope-from obrien) Date: Sun, 19 Nov 2000 08:34:38 -0800 From: "David O'Brien" To: Mark Murray Cc: arch@freebsd.org Subject: Re: "monotonic" counter commit candidate. Reviews, please. Message-ID: <20001119083438.B39585@dragon.nuxi.com> Reply-To: arch@freebsd.org References: <200011190932.eAJ9WBJ14810@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011190932.eAJ9WBJ14810@gratis.grondar.za>; from mark@grondar.za on Sun, Nov 19, 2000 at 11:32:02AM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 19, 2000 at 11:32:02AM +0200, Mark Murray wrote: > Index: alpha/include/systm.h > =================================================================== > RCS file: systm.h > diff -N systm.h > --- /dev/null Sun Nov 19 11:09:56 2000 > +++ systm.h Sat Nov 18 23:32:02 2000 Why do we need a new header just for this? There is no other existing per-platform header this could go into? And if we have to make a new header, can we name it something more descriptive than "systm", or at least spell it correctly so says "look in system dot h" the listener has a chance of finding more easily. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 10:23: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id E5AD137B479 for ; Sun, 19 Nov 2000 10:22:58 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAJIMZJ15840; Sun, 19 Nov 2000 20:22:39 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011191822.eAJIMZJ15840@gratis.grondar.za> To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. References: In-Reply-To: ; from Bruce Evans "Mon, 20 Nov 2000 01:12:28 +1100." Date: Sun, 19 Nov 2000 20:22:35 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'm not looking for random. I'm looking for a fast counter. > > You seem to want more than a fast counter. The following implements a > fast counter: > --- > u_int fast_counter; > > ++fast_counter; ...one which to be scheduled to be executed; rdtsc() does not; all I need to do is read it. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 10:26:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 09E6237B479 for ; Sun, 19 Nov 2000 10:26:19 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAJIPSJ15851; Sun, 19 Nov 2000 20:25:28 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011191825.eAJIPSJ15851@gratis.grondar.za> To: "Justin T. Gibbs" Cc: arch@FreeBSD.ORG Subject: Re: "monotonic" counter commit candidate. Reviews, please. References: <200011191454.eAJEsO432829@aslan.scsiguy.com> In-Reply-To: <200011191454.eAJEsO432829@aslan.scsiguy.com> ; from "Justin T. Gibbs" "Sun, 19 Nov 2000 07:54:24 MST." Date: Sun, 19 Nov 2000 20:25:28 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >I have incorporated a whole bunch more of ideas and concerns from John > >Baldein and Bruce Evans. > > Is rdtsc defined in the i386/i486 only case? It is defined, but it will not work. In fact, if it is executed, the program will likely dump core (or panic if in kernel). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 10:43:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 6892837B479 for ; Sun, 19 Nov 2000 10:43:11 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAJIh8J15901 for ; Sun, 19 Nov 2000 20:43:08 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011191843.eAJIh8J15901@gratis.grondar.za> To: arch@freebsd.org Subject: Re: "monotonic" counter commit candidate. Reviews, please. References: <20001119083438.B39585@dragon.nuxi.com> In-Reply-To: <20001119083438.B39585@dragon.nuxi.com> ; from "David O'Brien" "Sun, 19 Nov 2000 08:34:38 PST." Date: Sun, 19 Nov 2000 20:43:08 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Why do we need a new header just for this? There is no other existing > per-platform header this could go into? And if we have to make a new > header, can we name it something more descriptive than "systm", or at > least spell it correctly so says "look in system dot h" the listener has > a chance of finding more easily. Bruce pointed out machine/cpu.h. Any objections? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 11:44:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 099E037B479 for ; Sun, 19 Nov 2000 11:44:45 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAJJieJ15985 for ; Sun, 19 Nov 2000 21:44:41 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011191944.eAJJieJ15985@gratis.grondar.za> To: arch@freebsd.org Subject: "monotime" counter - commit candidate #2 Date: Sun, 19 Nov 2000 21:44:40 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi It looks like we are converging, and that the bikeshed factor is gone! BDE has sent some useful comments, and I have incorporated them. We are ready for go. Green Light? M Index: alpha/include/cpu.h =================================================================== RCS file: /home/ncvs/src/sys/alpha/include/cpu.h,v retrieving revision 1.18 diff -u -d -r1.18 cpu.h --- alpha/include/cpu.h 2000/10/06 02:20:10 1.18 +++ alpha/include/cpu.h 2000/11/19 19:01:36 @@ -173,6 +173,16 @@ void trap __P((unsigned long, unsigned long, unsigned long, unsigned long, struct trapframe *)); +/* + * Return contents of in-cpu fast counter as a sort of "bogo-time" + * for non-critical timing. + */ +static __inline u_int64_t +get_cyclecount(void) +{ + return (alpha_rpcc()); +} + #endif /* _KERNEL */ #endif /* _ALPHA_CPU_H_ */ Index: i386/include/cpu.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/cpu.h,v retrieving revision 1.49 diff -u -d -r1.49 cpu.h --- i386/include/cpu.h 2000/10/27 08:30:56 1.49 +++ i386/include/cpu.h 2000/11/19 19:38:46 @@ -47,6 +47,8 @@ #include #include #include +#include +#include /* * definitions of cpu-dependent requirements @@ -133,6 +135,25 @@ void fork_trampoline __P((void)); void fork_return __P((struct proc *, struct trapframe)); + +/* + * Return contents of in-cpu fast counter as a sort of "bogo-time" + * for non-critical timing. + */ +static __inline u_int64_t +get_cyclecount(void) +{ +#if defined(I386_CPU) || defined(I486_CPU) + struct timespec tv; + + if ((cpu_feature & CPUID_TSC) == 0) { + nanotime(&tv); + return (tv.tv_sec * (u_int64_t)1000000000 + tv.tv_nsec); + } +#endif + return (rdtsc()); +} + #endif #endif /* !_MACHINE_CPU_H_ */ Index: i386/include/cpufunc.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/cpufunc.h,v retrieving revision 1.99 diff -u -d -r1.99 cpufunc.h --- i386/include/cpufunc.h 2000/10/12 17:05:33 1.99 +++ i386/include/cpufunc.h 2000/11/18 21:29:08 @@ -397,7 +397,7 @@ { u_int64_t rv; - __asm __volatile(".byte 0x0f, 0x31" : "=A" (rv)); + __asm __volatile("rdtsc" : "=A" (rv)); return (rv); } @@ -416,7 +416,7 @@ static __inline void wrmsr(u_int msr, u_int64_t newval) { - __asm __volatile(".byte 0x0f, 0x30" : : "A" (newval), "c" (msr)); + __asm __volatile("wrmsr" : : "A" (newval), "c" (msr)); } static __inline u_int Index: ia64/include/cpu.h =================================================================== RCS file: /home/ncvs/src/sys/ia64/include/cpu.h,v retrieving revision 1.5 diff -u -d -r1.5 cpu.h --- ia64/include/cpu.h 2000/10/16 08:54:40 1.5 +++ ia64/include/cpu.h 2000/11/19 19:01:21 @@ -166,6 +166,16 @@ void syscall __P((int, u_int64_t *, struct trapframe *)); void trap __P((int vector, int imm, struct trapframe *framep)); +/* + * Return contents of in-cpu fast counter as a sort of "bogo-time" + * for non-critical timing. + */ +static __inline u_int64_t +get_cyclecount(void) +{ + return (ia64_get_itc()); +} + #endif /* _KERNEL */ #endif /* _MACHINE_CPU_H_ */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 19 23:51:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 4C6B037B479 for ; Sun, 19 Nov 2000 23:51:45 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id AAA28650; Mon, 20 Nov 2000 00:52:21 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdAAAj0ai63; Mon Nov 20 00:52:12 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA03260; Mon, 20 Nov 2000 00:51:33 -0700 (MST) From: Terry Lambert Message-Id: <200011200751.AAA03260@usr06.primenet.com> Subject: Re: "Monotonic" counter/register call - commit candidate. To: eischen@vigrid.com (Daniel Eischen) Date: Mon, 20 Nov 2000 07:51:32 +0000 (GMT) Cc: mark@grondar.za (Mark Murray), arch@FreeBSD.ORG In-Reply-To: from "Daniel Eischen" at Nov 18, 2000 08:22:44 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I really hate "jiffie" and would prefer using just get_cyclecount > or even better get_counter. It would also be nice to know what > resolution the counter was, perhaps get_counter_res(). Isn't that obvious from the name of the function? A jiffy is 1/60th of a second, and has been at least since the early 6800 machines came out, if not before. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 2: 7: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 9142D37B479 for ; Mon, 20 Nov 2000 02:06:56 -0800 (PST) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAKA6RJ18636; Mon, 20 Nov 2000 12:06:28 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011201006.eAKA6RJ18636@gratis.grondar.za> To: Terry Lambert Cc: eischen@vigrid.com (Daniel Eischen), arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. References: <200011200751.AAA03260@usr06.primenet.com> In-Reply-To: <200011200751.AAA03260@usr06.primenet.com> ; from Terry Lambert "Mon, 20 Nov 2000 07:51:32 GMT." Date: Mon, 20 Nov 2000 12:06:27 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I really hate "jiffie" and would prefer using just get_cyclecount > > or even better get_counter. It would also be nice to know what > > resolution the counter was, perhaps get_counter_res(). > > Isn't that obvious from the name of the function? A jiffy is 1/60th > of a second, and has been at least since the early 6800 machines came > out, if not before. The word "jiffy" has been long dropped. The resolution of the counter is whatever the tsc register (in Pentium) is, whatever the pcc is in the Alpha, whatever the itc reg is on IA64. (..and so on). Architectures that do not have such a register will use nanotime(9) reduced to an integral number of nanoseconds. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 5:33:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id C36EB37B479; Mon, 20 Nov 2000 05:33:29 -0800 (PST) Received: from victoria-203.budapest.interware.hu ([195.70.63.203] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13xr4X-0004nJ-00; Mon, 20 Nov 2000 14:33:25 +0100 Message-ID: <3A192821.13463950@elischer.org> Date: Mon, 20 Nov 2000 05:33:21 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: jasone@freebsd.org, arch@freebsd.org, smp@freebsd.org Subject: Re: Threads (KSE etc) comments References: <3A15A2C1.1F3FB6CD@elischer.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Netscape made an unholy mess of this. I'm going to try send it again and see if I can unscramble the mess. I also clarified a few points. julian. Julian Elischer wrote: > Hi jason. > I read your Nov 7 doc on the threading model. I have a few comments.. I've been thinking about the scheduling queues, and how to make sure that the process (KSEG actually) acts fairly with respect to other processes. I was confised for a while by your description. I think part of my confusion came from something that we specified in the meeting but has not been written in your document directly. Let me see if we are agreed on what we decided.. A KSEG can only have as a maximum N KSEs associated with it, where N is the number of processors, (unless artificially reduced by a lower concurency declaration). (you said this but only indirectly). In general, KSEs are each assigned to a processor. They do not in general move between processors unless some explicit adjustment is being made(*), and as a general rule, two KSEs will not be assigned to the same processor. (in some transitional moments this may be allowed to briefly happen) This in general if you run a KSEC on the same KSE it was run on last time, you should be on the same processor, (and get any affinity advantages that might exist). (*)I am inclined to make the requirement of binding KSEs to processors HARD,as this allows us to simplify some later decisions. For example, if we hard bind KSEs to procesors then since we assign a different communications mailbox for each KSE we create, we can be sure that different KSEs will never preempt each other when writing out to their mailboxes. this also means that since there can only be one UTS incarnation active per KSE (or one KSE per UTS incarnation), that we can not have a UTS preempted by another incarnation on the same processor. We can therefore make sure that there needs to be no locking on mailboxes, or even any checking. I think this is what we decided.. is this correct? The binding is not really mentioned in your document. When we were talking about it, (at least in my memory) Each KSE had a mailbox. My memory of this was that we called a KSE creation call with a different argument, thus each KSE had a different return stack frame when it made upcalls. In the version you have outlined, there is no KSE creation call only KSEG creation calls. Thus all upcalls have the same frame, and there is the danger of colliding upcalls for different processors. I think it works more naturally with everything just 'falling into place' if we have calls to create KSEs rather than KSEGs. The "make KSEG" call is simply a version of the "make KSE" call that also puts it into the new different group. You are left with teh very first 'original' thread being different in my shceme, but my answer to this would be to simply make the first "make KSE" call reuse the current stack etc. and not return a new one. My memory (where is that photo of the whiteboard that Nicole was supposed to send us) is that each KSE is assigned a differnt mailbox address in userland, which is associated with the frame that it will do upcalls on. One of the fields of the mailbox contains a pointer to a userland context structure which contains apece where the KSE should dump the user context should it need to, and a pointer to other such structures. This structure is defined by the kernel, but included in the UTS's 'per thread info'. Since there is one per thread, there is never a problem in running out of them when the kernel links them together in a linked list of completed operations. This is the structure you were talking about as if it were on the KSE upcall stack. In my memory it was preallocated as part of the thread information and completed (or suspended threads (KSECs) are simply linked together inj a list by the kernel, but it doesn;t have to allocate them. (so you discussion about how many need to be provided for is short circuited. When the thread makes a system call, the KSE looks in the mailbox for the context structure for this thread, and if the thread blocks or resumes, it can save any information it needs to tell the UTS there. The UTS sets the pointer into the mailbox when it schedules the thread, so even involintary blockages (e.g. page faults) have the pointer available. When the UTS is running it's own work, it ZERO's this pointer, which lets the kernel know that it is not really in a safe state for pre-emmpting. I think that we decided that a page fault in the UTS simply blocked until it was satisfied. When an upcall occurs, the stack frame it occurs on, and hence the mailbox pointed to are automatically correct, so the UTS doesn't even have to look it up. (the mailbox is allocated as a local variable in the frame of the KSE creation call and is this in the local frame of the upcall. This is something like I imagined the UTS would do to fire off a new KSE. The reason I was thinking of it this way was so that each KSE has a UTS supplied mailbox and (smallish) stack. /* * use make_new_kse() to do exactly that. * Returns -1 on failure and 1 on success. * * cookie allows the UTS to have it's own way of identifying the * KSE/thread. * This stack is effectively lost to us so we first switch * to a small throw-away stack. It need only have enough space in it for * the upcalls to call the UTS, and whatever the UTS will need. * Some time after creation, there will be an upcall on the new KSE * looking for work. * I could imagine wiring this UTS stack down.. */ void start_new_kse(void * cookie, jmp_buf *jb) /*XXX is jb right? */ { struct kse_mailbox; int return_value; bzero(kse_mailbox, sizeof(kse_mailbox)); return_value = kse_new(&kse_mailbox); switch (return_value) { case -1:  perror("make_new_kse() failed"); _longjmp(jb, -1); case 0: printf ("successfully created kse %d\n", kse_mailbox.kse_id); _longjmp(jb, 1); exit (1); /* not reached */ default: printf(" An upcall of type %d occured\n", return_value); uts_scheduler(cookie, &kse_mailbox, return_value); /* must never return */ printf ("it returned!\n"); exit (1); } } make_new_kse(void * cookie) { int retval; jmp_buf env; if ((retval = _setjmp(env)) == 0) { load_new_stack() /* load a new smaller stack, but copy the top 100 bytes or so from the old stack so that our local variables appear to be the same. */ start_new_kse(cookie, env); /* not reached */ } return (retval) } When we have per-processor scheduling queues, there is only at most ONE KSE from any given KSEG in the scheduling queues for any given processor. With the single scheduling queue we have now do we allow N to be in the queues at once? (or do we put the KSEG in instead?) The terms KSE etc. have probably served their useful life. It's time to think of or find names that really describe them better KSE -- a per process processor.. slot? openning? (a-la CAM/SCSI) KSEC ---- stack plus context... KSC..trying to do something (task?) KSEG ---- a class of schedulable entities.. A slot cluster? :-) PROC ---- probably needs to stay the same. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 9:41:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sampnt500.avantgo.com (unknown [209.220.59.68]) by hub.freebsd.org (Postfix) with ESMTP id 46A5837B479; Mon, 20 Nov 2000 09:41:10 -0800 (PST) Received: by sampnt500.avantgo.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 09:42:06 -0800 Received: from river.avantgo.com ([10.1.30.114]) by sampnt500.avantgo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id W0LZ2H5X; Mon, 20 Nov 2000 09:41:56 -0800 From: Scott Hess To: Julian Elischer Cc: jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Date: Mon, 20 Nov 2000 09:45:53 -0800 (PST) Subject: Re: Threads (KSE etc) comments In-Reply-To: <3A192821.13463950@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have seen the notion of limiting KSE's to the number of CPUs mentioned a number of times on the arch and smp lists. This is presumably done to maximize performance of CPU-bound and network-I/O-bound programs. Please keep disk-I/O-bound programs in mind. The current (3.x/4.x) pthreads implementation is horrid for programs bound by disk I/O. If you have a single multithreaded process doing lots of disk I/Os (let's call it MySQL), then it effectively becomes seek constrained. Converting from single disk to a 6 disk hardware RAID only gains perhaps %20 in throughput, even though throughput should at least double or triple. My informal testing under 3.x with a 6 disk striped set indicated that maximum throughput occurred with 8 seperate processes (running 8 seperate loads), so long as the CPU didn't become a bottleneck. With 1 disk, the maximum was more like three processes - but it was still more than the single process your posting would restrict things to. Presumably more disks would want more processes, with some upper limit where more processes don't help. [No, I don't have the bandwidth to contribute work at this time. I might be able to scrape together some time to characterize the issue more precisely, though, if I knew that my results were going to get folded in. My main goal is that after everything is said and done, there isn't a huge hole intentionally designed into the system!] Later, scott On Mon, 20 Nov 2000, Julian Elischer wrote: > A KSEG can only have as a maximum N KSEs associated with it, where N is > the number of processors, (unless artificially reduced by a lower > concurency declaration). (you said this but only indirectly). In > general, KSEs are each assigned to a processor. They do not in general > move between processors unless some explicit adjustment is being > made(*), and as a general rule, two KSEs will not be assigned to the > same processor. (in some transitional moments this may be allowed to > briefly happen) This in general if you run a KSEC on the same KSE it was > run on last time, you should be on the same processor, > (and get any affinity advantages that might exist). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 10:10:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6A41C37B479; Mon, 20 Nov 2000 10:10:33 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA21043; Mon, 20 Nov 2000 13:10:11 -0500 (EST) Date: Mon, 20 Nov 2000 13:10:10 -0500 (EST) From: Daniel Eischen To: Scott Hess Cc: Julian Elischer , jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 20 Nov 2000, Scott Hess wrote: > I have seen the notion of limiting KSE's to the number of CPUs mentioned a > number of times on the arch and smp lists. This is presumably done to > maximize performance of CPU-bound and network-I/O-bound programs. > > Please keep disk-I/O-bound programs in mind. The current (3.x/4.x) > pthreads implementation is horrid for programs bound by disk I/O. If you > have a single multithreaded process doing lots of disk I/Os (let's call it > MySQL), then it effectively becomes seek constrained. Converting from > single disk to a 6 disk hardware RAID only gains perhaps %20 in > throughput, even though throughput should at least double or triple. > > My informal testing under 3.x with a 6 disk striped set indicated that > maximum throughput occurred with 8 seperate processes (running 8 seperate > loads), so long as the CPU didn't become a bottleneck. With 1 disk, the > maximum was more like three processes - but it was still more than the > single process your posting would restrict things to. Presumably more > disks would want more processes, with some upper limit where more > processes don't help. You can't compare one multi-threaded process with our current threads implementation to one KSE/KSEG. With one CPU, and therefore 1 KSE within the KSEG, a thread really blocks in the kernel waiting for disk I/O. Unlike our current threads implementation, when that happens under the KSE implementation, the KSE continues to run by issuing an upcall to the threads library to schedule another thread. This can repeat itself, allowing many threads to be blocked in the kernel waiting for disk I/O, but the KSE will not block unless it runs out of resources (needed to save kernel state for threads blocked in the kernel), is preempted by a higher priority process or kernel thread, or exhausts its quantum. With 2 CPUs, you could have 2 KSEs within the KSEG. Nothing changes except that the KSEG workload is spread across 2 KSEs running on different CPUs. The quantum for the KSEG, regardless of whether there are 1 or more KSEs associated with it, remains the same (I would advocate a separate quantum in this case, but I think I'm outvoted on that front). This is all for PTHREAD_SCOPE_PROCESS threads. PTHREAD_SCOPE_SYSTEM threads will be bound to their own KSEG with one KSE. These will act more like LinuxThreads; when one of these threads block in the kernel, another one will not be executed (because there are no other threads allocated for that KSEG/KSE by the threads library). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 10:26:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id EB4FE37B4CF for ; Mon, 20 Nov 2000 10:26:26 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAKIQOQ25713; Mon, 20 Nov 2000 11:26:25 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id eAKIQKG07857; Mon, 20 Nov 2000 11:26:20 -0700 (MST) Message-Id: <200011201826.eAKIQKG07857@billy-club.village.org> To: Keith Jones Subject: Re: BootEasy and PC-XT partitions [was Re: Dedicated disks...] Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 20 Nov 2000 17:43:08 GMT." <20001120174308.A14723@moose.bri.hp.com> References: <20001120174308.A14723@moose.bri.hp.com> <200011201003.eAKA3RS01865@possum.os2.ami.com.au> Date: Mon, 20 Nov 2000 11:26:19 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ bcc'd to stable, moved to arch ]] In message <20001120174308.A14723@moose.bri.hp.com> Keith Jones writes: : Additionally, how many sectors can we actually *guarantee* are there if we : were to include support for legacy IDE disks? (I'm guessing some of the : older ones had less than 63spt, though all mine ended up in the skip long : ago so I can't tell anymore...) The DOC2k that I used at have 2spt. Yes, 2spt. But I generally don't have agressive needs for my boot loader on these systems. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 10:55:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from KIWI-Computer.com (kiwi-computer.com [63.224.10.3]) by hub.freebsd.org (Postfix) with ESMTP id 9F8D437B479 for ; Mon, 20 Nov 2000 10:55:10 -0800 (PST) Received: (from freebsd@localhost) by KIWI-Computer.com (8.9.3/8.9.3) id MAA49580; Mon, 20 Nov 2000 12:52:46 -0600 (CST) (envelope-from freebsd) From: FreeBSD Filter Message-Id: <200011201852.MAA49580@KIWI-Computer.com> Subject: Re: Removal of Disklabel (was: Re: Dangerously Dedicated) In-Reply-To: <14873.28040.451463.172207@nomad.yogotech.com> from Nate Williams at "Nov 20, 2000 11:29:28 am" To: Nate Williams Date: Mon, 20 Nov 2000 12:52:46 -0600 (CST) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cc'd to freebsd-arch instead of stable: > > > That's not good enough. The PC architecture limits us to 4-total > > > partitions, which isn't good enough. It's not even good enough for M$, > > > so they invented 'extended partitions, which is a M$-only feature. > > > > Just because microsnot invented it doesn't mean they're the only ones using > > it. Linux does, and I'm sure others do too. > > Linux is the *only* OS that I'm aware that follows M$ lead. I think > it's that way because initially most of the Linux developers were M$ > users, whereas most of the BSD developers were unix users who wanted to > run a real OS on their PC. Totally different perspectives. true. But we're not talking about OS issues, we're talking about remaining compatible with other operating systems, and sadly this includes microcrap products as well as linux and the like. And if BIOSes keep going the way they're going, we'll be forced to use the extended partitions or whatnot anyway (if we go over 4). > (I for one would be *very* annoyed to see FreeBSD change it's disk > format to be more M$-like, since it would be a gratiutious that would > cause endless grief for existing installations, and it's bowing even > more to M$.) 1). the BIOSes are bowing to m$ anyways... 2). existing installations would not be affected, only new installations would "renumber" the slices-- we would have to provide functionality in dealing with the current labels as well as the "true slices" including extended. The transition would be painless. 3). New installations would use the new numbering scheme and would use true "DOS partitions" (BSD slices), thus remaining completely compatible with other operating systems. 4). one could use fips or whatnot to move BSD slices around just like regular DOS partitions. This would gain us extra points in the eyes of many users. Note I'm not suggesting removing functionality, but making the installer (and thus the disklabel/slices) default to using true DOS-style partitions, much like linux does (I struggle to even suggest that). I personally wouldn't want FreeBSD to change its disk format again, but I think it's an eventuality and I'm willing to live with it. If we must, we should remain compatible with DOS. (now I need to take a shower to cleanse myself of that last statement!) Like I first stated, I'd be willing to help code the changes and test them, but first we need to reach an agreement on what to do, and to hear a little from the core team. --Rick C. Petty, aka Snoopy rick@kiwi-computer.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 10:58: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from KIWI-Computer.com (kiwi-computer.com [63.224.10.3]) by hub.freebsd.org (Postfix) with ESMTP id B543837B479 for ; Mon, 20 Nov 2000 10:58:02 -0800 (PST) Received: (from freebsd@localhost) by KIWI-Computer.com (8.9.3/8.9.3) id MAA49667; Mon, 20 Nov 2000 12:55:37 -0600 (CST) (envelope-from freebsd) From: FreeBSD Filter Message-Id: <200011201855.MAA49667@KIWI-Computer.com> Subject: Re: Removal of Disklabel In-Reply-To: <73213.974745548@winston.osd.bsdi.com> from Jordan Hubbard at "Nov 20, 2000 10:39:08 am" To: Jordan Hubbard Date: Mon, 20 Nov 2000 12:55:37 -0600 (CST) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > In a world where most people don't care about the architecture of an > > operating system, I think that this would put a friendlier face on > > FreeBSD. > > Well, why not prototype something up and show it to us? These things > don't write themselves. :) Ok. Any suggestions on a naming scheme? I'm all for /dev/hd01a /dev/hd01b etc. (arg-- linux again, I hang my head in shame) I'll get to work on it right away... =) --Rick C. Petty, aka Snoopy rick@kiwi-computer.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 11:15:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 0228437B4C5 for ; Mon, 20 Nov 2000 11:15:54 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eAKJFRI73571; Mon, 20 Nov 2000 11:15:27 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: FreeBSD Filter Cc: freebsd-arch@freebsd.org Subject: Re: Removal of Disklabel In-Reply-To: Message from FreeBSD Filter of "Mon, 20 Nov 2000 12:55:37 CST." <200011201855.MAA49667@KIWI-Computer.com> Date: Mon, 20 Nov 2000 11:15:27 -0800 Message-ID: <73567.974747727@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok. Any suggestions on a naming scheme? I'm all for /dev/hd01a /dev/hd01b > etc. (arg-- linux again, I hang my head in shame) Well, I don't think you'll get anywhere by renaming the devices or changing the conventions we already have, you simply need to consolidate the fdisk/disklabel process. You can do that without going to a Linux naming format. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 11:21:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 1A4C337B4CF for ; Mon, 20 Nov 2000 11:21:25 -0800 (PST) Received: from dragon.nuxi.com (root@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA20891; Mon, 20 Nov 2000 11:21:23 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id eAKJLLO10410; Mon, 20 Nov 2000 11:21:21 -0800 (PST) (envelope-from obrien) Date: Mon, 20 Nov 2000 11:21:20 -0800 From: "David O'Brien" To: FreeBSD Filter Cc: freebsd-arch@freebsd.org Subject: Re: Removal of Disklabel (was: Re: Dangerously Dedicated) Message-ID: <20001120112120.A10354@dragon.nuxi.com> Reply-To: arch@freebsd.org References: <14873.28040.451463.172207@nomad.yogotech.com> <200011201852.MAA49580@KIWI-Computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011201852.MAA49580@KIWI-Computer.com>; from freebsd@KIWI-Computer.com on Mon, Nov 20, 2000 at 12:52:46PM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 20, 2000 at 12:52:46PM -0600, FreeBSD Filter wrote: > 2). existing installations would not be affected, only new installations > would "renumber" the slices-- we would have to provide functionality in > dealing with the current labels as well as the "true slices" including > extended. The transition would be painless. Thus you must keep all the current bits for doing this in the kernel, etc al for compat reasons. Yuck. We don't need YET another way of doing things. Just look at all the crap in the i386 locore.s for all the various ways of getting the boot info (see recover_bootinfo, etc). Now compare to the Alpha. The Alpha has a single way. Thus the code is cleaner and much more maintainable as there is no backwards compatibility that must be maintained. We have a working way, lets not obfuscate things by having YET another way. > 3). New installations would use the new numbering scheme and would use true > "DOS partitions" (BSD slices), thus remaining completely compatible with ^^^ They aren't "[ms-]DOS", they aren't "M$", they are IBM/PC or BIOS partitions. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 12:53:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id E670337B479 for ; Mon, 20 Nov 2000 12:53:47 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id MAA15624; Mon, 20 Nov 2000 12:53:47 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda15622; Mon Nov 20 12:53:32 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAKKrNd15505; Mon, 20 Nov 2000 12:53:23 -0800 (PST) Message-Id: <200011202053.eAKKrNd15505@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdM15494; Mon Nov 20 12:52:45 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cschuber To: Jordan Hubbard Cc: Cy Schubert - ITSD Open Systems Group , Stijn Hoop , FreeBSD , arch@FreeBSD.ORG Subject: Re: Removal of Disklabel In-reply-to: Your message of "Mon, 20 Nov 2000 10:39:08 PST." <73213.974745548@winston.osd.bsdi.com> Date: Mon, 20 Nov 2000 12:52:45 -0800 From: Cy Schubert Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -stable removed from the cc list and -arch substituted. In message <73213.974745548@winston.osd.bsdi.com>, Jordan Hubbard writes: > > In a world where most people don't care about the architecture of an > > operating system, I think that this would put a friendlier face on > > FreeBSD. > > Well, why not prototype something up and show it to us? These things > don't write themselves. :) > > - Jordan I'm willing to do the work. Should I use sysinstall as a basis for this work or create something entirely new? The discussion continues. I will put together a strawman first so I have some clear direction and consensus. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 13: 3:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id B238637B479 for ; Mon, 20 Nov 2000 13:03:37 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eAKL2rI74135; Mon, 20 Nov 2000 13:02:54 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Cy Schubert - ITSD Open Systems Group Cc: Stijn Hoop , FreeBSD , arch@FreeBSD.ORG Subject: Re: Removal of Disklabel In-Reply-To: Message from Cy Schubert of "Mon, 20 Nov 2000 12:52:45 PST." <200011202053.eAKKrNd15505@passer.osg.gov.bc.ca> Date: Mon, 20 Nov 2000 13:02:53 -0800 Message-ID: <74131.974754173@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm willing to do the work. Should I use sysinstall as a basis for > this work or create something entirely new? It's really up to you, whatever's easiest. I might only suggest that you put the bulk of this into a library of some sort so that either sysinstall or a command-line oriented tool could use it. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 13:57:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 0C8D137B4D7; Mon, 20 Nov 2000 13:57:49 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id OAA02759; Mon, 20 Nov 2000 14:53:37 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAm6aate; Mon Nov 20 14:52:34 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA02067; Mon, 20 Nov 2000 14:56:36 -0700 (MST) From: Terry Lambert Message-Id: <200011202156.OAA02067@usr08.primenet.com> Subject: Re: Threads (KSE etc) comments To: scott@avantgo.com (Scott Hess) Date: Mon, 20 Nov 2000 21:56:36 +0000 (GMT) Cc: julian@elischer.org (Julian Elischer), jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG In-Reply-To: from "Scott Hess" at Nov 20, 2000 09:45:53 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have seen the notion of limiting KSE's to the number of CPUs mentioned a > number of times on the arch and smp lists. This is presumably done to > maximize performance of CPU-bound and network-I/O-bound programs. A KSE is a "reservation for quantum". It is effectively a quantum holder. The quantum can be spread against multiple threads in user space. Except on multiple CPUs, which would permit multiple KSEs, all CPU utilization is serialized through the scheduler anyway. What a KSE buys you is thread group locality for context switcthes, which is something that is computationally difficult to achieve satisfactorily in a Linux or SVR4 approach to kernel threading, since it can quickly lead to starvation deadlock, where a threaded process gets affinity preference for its ready-to-run threads in the scheduler, thus starving everything else in the scheduler queue which is not the threaded process. In other words, it's incredibly hard to achieve affinity after you have broken the quantum-process accounting connection. KSEs preserve this connection. This typically means that, if you are attempting to use multiple threads to unfairly compete for quantum, you will have to follow the scheduler priority rules instead (many threads programmers use threads in an attempt to subvert the scheduler policy without resorting to increased priviledges; this is wrong). So your examples are all workable, merely by providing multiple user space threads. > On Mon, 20 Nov 2000, Julian Elischer wrote: > > A KSEG can only have as a maximum N KSEs associated with it, where N is > > the number of processors, (unless artificially reduced by a lower > > concurency declaration). (you said this but only indirectly). In > > general, KSEs are each assigned to a processor. They do not in general > > move between processors unless some explicit adjustment is being > > made(*), and as a general rule, two KSEs will not be assigned to the > > same processor. (in some transitional moments this may be allowed to > > briefly happen) This in general if you run a KSEC on the same KSE it was > > run on last time, you should be on the same processor, > > (and get any affinity advantages that might exist). I really, really disagree with Julian's statement about not assigning multiple KSEs to the same processor. There are perfectly valid loading reasons (e.g. two KSEs that each take 30% of the CPU, cooperating, with one CPU with a process that takse 90% of the CPU, while the other CPU is only at 60% utilization, etc.). There is also the PTHREAD_SCOPE_SYSTEM scheduling; one can easily conceive of a multithreading application, where one thread in the total list of threads needs to run with a real time priority to insure rapid interacative response, with metered intervals. One example would be a DVD player, where the rendering needs to occur at fixed intervals with no latency, whereas the fuffer-refill from the DVDROM, and the control functons for the program, overall, can run in normal priority threads. So I think there is a good argument for needing to support in the kernel the idea of multiple KSEs on a single processor; I understand Julian's anxiety about what this could do to the complexity of the sleep queues, but with respect to everyone, if the task's too complex, then stay out of the kernel (it's not too complex for Julian, it's just I don't think that the kernel should have to be written on the computer science equivalent of a 6th grade reading leveli: if it can't be understood by everyone, too bad: most people couldn't tell you how the ignition system in their car works, either). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 14: 5:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 00F6337B4E5; Mon, 20 Nov 2000 14:05:22 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id PAA09966; Mon, 20 Nov 2000 15:05:57 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAuVaGAt; Mon Nov 20 15:05:52 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA02205; Mon, 20 Nov 2000 15:05:14 -0700 (MST) From: Terry Lambert Message-Id: <200011202205.PAA02205@usr08.primenet.com> Subject: Re: Threads (KSE etc) comments To: eischen@vigrid.com (Daniel Eischen) Date: Mon, 20 Nov 2000 22:05:14 +0000 (GMT) Cc: scott@avantgo.com (Scott Hess), julian@elischer.org (Julian Elischer), jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG In-Reply-To: from "Daniel Eischen" at Nov 20, 2000 01:10:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > With 2 CPUs, you could have 2 KSEs within the KSEG. Nothing changes > except that the KSEG workload is spread across 2 KSEs running on > different CPUs. The quantum for the KSEG, regardless of whether > there are 1 or more KSEs associated with it, remains the same > (I would advocate a separate quantum in this case, but I think > I'm outvoted on that front). I have to disagree. Doing inter-CPU quantum accounting is a _big_ mistake. The reason that it would happen this way in the current code is that there is not the concept of per CPU run queues, something which is absolutely necesary, going forward. I think the only policy decision that should require priviledges in this case is M KSEs in an N CPU system, where M>N. For the most part, I would argue that this limitation can be enforced transparently, in the user space portion of the threads scheduler, and that overriding it requires priviledge. I might go so far as to say that the only place it is reasonable to override this is the PTHREAD_SCOPE_SYSTEM case, and/or for RT priority for one or more threads (which already requires priviledges). Competing for quantum on a single CPU as if you were more than one process, well.... that should take more than one process, unless you have priviledges. One gross hack might be to limit the number of total KSEs to the number of permitted child processes for a given process, but I'd hesitate to encourage people to use the not generally exposed and non (POSIX) standard interfaces that would be needed for a process to try to do this automatically. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 14:26:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 289CD37B479; Mon, 20 Nov 2000 14:26:09 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAKMQ7H87673; Mon, 20 Nov 2000 14:26:07 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001119083438.B39585@dragon.nuxi.com> Date: Mon, 20 Nov 2000 14:26:40 -0800 (PST) From: John Baldwin To: "David O'Brien" Subject: Re: "monotonic" counter commit candidate. Reviews, please. Cc: arch@FreeBSD.org, Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 19-Nov-00 David O'Brien wrote: > On Sun, Nov 19, 2000 at 11:32:02AM +0200, Mark Murray wrote: >> Index: alpha/include/systm.h >> =================================================================== >> RCS file: systm.h >> diff -N systm.h >> --- /dev/null Sun Nov 19 11:09:56 2000 >> +++ systm.h Sat Nov 18 23:32:02 2000 > > > Why do we need a new header just for this? There is no other existing > per-platform header this could go into? And if we have to make a new > header, can we name it something more descriptive than "systm", or at > least spell it correctly so says "look in system dot h" the listener has > a chance of finding more easily. Both machine/cpufunc.h and machine/clock.h were shot down with valid reasons. One could argue that this provides an MI api that is more or less a library function. A similar function that wasn't so MD specific would be implemented in libkern. libkern's prototypes are in sys/systm.h. The natural name for a MD portion of sys/systm.h is machine/systm.h. There is already tons of precedent for this. This has already been discussed to death. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 14:32:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 23F7D37B657; Mon, 20 Nov 2000 14:32:05 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA02819; Mon, 20 Nov 2000 17:31:42 -0500 (EST) Date: Mon, 20 Nov 2000 17:31:42 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Scott Hess , Julian Elischer , jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments In-Reply-To: <200011202205.PAA02205@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 20 Nov 2000, Terry Lambert wrote: > > With 2 CPUs, you could have 2 KSEs within the KSEG. Nothing changes > > except that the KSEG workload is spread across 2 KSEs running on > > different CPUs. The quantum for the KSEG, regardless of whether > > there are 1 or more KSEs associated with it, remains the same > > (I would advocate a separate quantum in this case, but I think > > I'm outvoted on that front). > > I have to disagree. Doing inter-CPU quantum accounting is a > _big_ mistake. The reason that it would happen this way in > the current code is that there is not the concept of per CPU > run queues, something which is absolutely necesary, going > forward. So you agree with me then? > I think the only policy decision that should require priviledges > in this case is M KSEs in an N CPU system, where M>N. For the > most part, I would argue that this limitation can be enforced > transparently, in the user space portion of the threads scheduler, > and that overriding it requires priviledge. I might go so far > as to say that the only place it is reasonable to override this > is the PTHREAD_SCOPE_SYSTEM case, and/or for RT priority for one > or more threads (which already requires priviledges). I agree also. > Competing for quantum on a single CPU as if you were more than > one process, well.... that should take more than one process, > unless you have priviledges. With the exception of PTHREAD_SCOPE_PROCESS, where the thread scheduler (UTS hereafter) allocates/requests one KSEG with exactly one KSE. > One gross hack might be to limit the number of total KSEs to > the number of permitted child processes for a given process, > but I'd hesitate to encourage people to use the not generally > exposed and non (POSIX) standard interfaces that would be > needed for a process to try to do this automatically. You have to be careful with terminology. If we're going by what Jason has defined in his paper, the KSEG is the entity that has the quantum, not the KSE. So the KSEGs would be limited to the permitted number of child processes. If you want to have a separate quantum for each KSE, then you can probably eliminate the KSEG. I've made this comment also. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 14:39:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 67E3737B479; Mon, 20 Nov 2000 14:39:28 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA03845; Mon, 20 Nov 2000 17:39:06 -0500 (EST) Date: Mon, 20 Nov 2000 17:39:06 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Scott Hess , Julian Elischer , jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments In-Reply-To: <200011202156.OAA02067@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 20 Nov 2000, Terry Lambert wrote: > > I have seen the notion of limiting KSE's to the number of CPUs mentioned a > > number of times on the arch and smp lists. This is presumably done to > > maximize performance of CPU-bound and network-I/O-bound programs. > > A KSE is a "reservation for quantum". It is effectively a quantum > holder. The quantum can be spread against multiple threads in user > space. Except on multiple CPUs, which would permit multiple KSEs, > all CPU utilization is serialized through the scheduler anyway. This isn't what has been defined. The KSEG is the "reservation for quantum", but I do tend to agree that it should in fact be the KSE. > > On Mon, 20 Nov 2000, Julian Elischer wrote: > > > A KSEG can only have as a maximum N KSEs associated with it, where N is > > > the number of processors, (unless artificially reduced by a lower > > > concurency declaration). (you said this but only indirectly). In > > > general, KSEs are each assigned to a processor. They do not in general > > > move between processors unless some explicit adjustment is being > > > made(*), and as a general rule, two KSEs will not be assigned to the > > > same processor. (in some transitional moments this may be allowed to > > > briefly happen) This in general if you run a KSEC on the same KSE it was > > > run on last time, you should be on the same processor, > > > (and get any affinity advantages that might exist). > > I really, really disagree with Julian's statement about not > assigning multiple KSEs to the same processor. There are > perfectly valid loading reasons (e.g. two KSEs that each take > 30% of the CPU, cooperating, with one CPU with a process that > takse 90% of the CPU, while the other CPU is only at 60% > utilization, etc.). > > There is also the PTHREAD_SCOPE_SYSTEM scheduling; one can > easily conceive of a multithreading application, where one thread > in the total list of threads needs to run with a real time > priority to insure rapid interacative response, with metered > intervals. One example would be a DVD player, where the > rendering needs to occur at fixed intervals with no latency, > whereas the fuffer-refill from the DVDROM, and the control > functons for the program, overall, can run in normal priority > threads. We have an application that has very similar needs. Right now we use Solaris, with some threads in RT and some not in RT. I intend on making this work in FreeBSD also. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 21:19:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0AC2E37B4CF for ; Mon, 20 Nov 2000 21:19:41 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAL5JdQ28801; Mon, 20 Nov 2000 22:19:40 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA31460; Mon, 20 Nov 2000 22:19:39 -0700 (MST) Message-Id: <200011210519.WAA31460@harmony.village.org> To: chad@DCFinc.com Subject: Re: Dangerously Dedicated Cc: arch@freebsd.org In-reply-to: Your message of "Mon, 20 Nov 2000 22:17:18 MST." <200011210517.WAA08133@freeway.dcfinc.com> References: <200011210517.WAA08133@freeway.dcfinc.com> Date: Mon, 20 Nov 2000 22:19:39 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011210517.WAA08133@freeway.dcfinc.com> "Chad R. Larson" writes: : Do we want to start a new thread on what exactly =is= the : authoritative documentation for PC architecture? It doesn't matter in this case. There is none. Only new machines whose bioses do care, any prior art not with standing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 22:10:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id DD2E137B479; Mon, 20 Nov 2000 22:10:49 -0800 (PST) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAL6AiJ23116; Tue, 21 Nov 2000 08:10:45 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011210610.eAL6AiJ23116@gratis.grondar.za> To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: "monotonic" counter commit candidate. Reviews, please. References: In-Reply-To: ; from John Baldwin "Mon, 20 Nov 2000 14:26:40 PST." Date: Tue, 21 Nov 2000 08:10:40 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Both machine/cpufunc.h and machine/clock.h were shot down with valid reasons. machine/systm.h also (by bde). > One could argue that this provides an MI api that is more or less a library > function. A similar function that wasn't so MD specific would be implemented > in libkern. libkern's prototypes are in sys/systm.h. The natural name for a > MD portion of sys/systm.h is machine/systm.h. There is already tons of > precedent for this. This has already been discussed to death. Its now in machine/cpu.h M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 23:35:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 8A6A037B479; Mon, 20 Nov 2000 23:35:42 -0800 (PST) Received: from pretoria-36.budapest.interware.hu ([195.70.53.100] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13y7xr-00015F-00; Tue, 21 Nov 2000 08:35:39 +0100 Message-ID: <3A1A25C6.99B1B8F3@elischer.org> Date: Mon, 20 Nov 2000 23:35:34 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen Cc: Scott Hess , jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > With 2 CPUs, you could have 2 KSEs within the KSEG. Nothing changes > except that the KSEG workload is spread across 2 KSEs running on > different CPUs. The quantum for the KSEG, regardless of whether > there are 1 or more KSEs associated with it, remains the same > (I would advocate a separate quantum in this case, but I think > I'm outvoted on that front). not entirely I think a process using two KSEs in a KSEG should be charged for 2. > > This is all for PTHREAD_SCOPE_PROCESS threads. PTHREAD_SCOPE_SYSTEM > threads will be bound to their own KSEG with one KSE. These will > act more like LinuxThreads; when one of these threads block in > the kernel, another one will not be executed (because there are no > other threads allocated for that KSEG/KSE by the threads library). well, it WILL do the upcall but the UTS will respond with "No new thread to schedule, please yield" > > -- > Dan Eischen > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 23:41:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id EEA2837B4D7; Mon, 20 Nov 2000 23:41:22 -0800 (PST) Received: from pretoria-36.budapest.interware.hu ([195.70.53.100] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13y83I-0001GV-00; Tue, 21 Nov 2000 08:41:17 +0100 Message-ID: <3A1A2717.3270D40F@elischer.org> Date: Mon, 20 Nov 2000 23:41:11 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Terry Lambert Cc: Scott Hess , jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments References: <200011202156.OAA02067@usr08.primenet.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > I have seen the notion of limiting KSE's to the number of CPUs mentioned a > > number of times on the arch and smp lists. This is presumably done to > > maximize performance of CPU-bound and network-I/O-bound programs. > > A KSE is a "reservation for quantum". It is effectively a quantum > holder. The quantum can be spread against multiple threads in user > space. Except on multiple CPUs, which would permit multiple KSEs, > all CPU utilization is serialized through the scheduler anyway. > > What a KSE buys you is thread group locality for context switcthes, > which is something that is computationally difficult to achieve > satisfactorily in a Linux or SVR4 approach to kernel threading, > since it can quickly lead to starvation deadlock, where a threaded > process gets affinity preference for its ready-to-run threads in > the scheduler, thus starving everything else in the scheduler queue > which is not the threaded process. > > In other words, it's incredibly hard to achieve affinity after > you have broken the quantum-process accounting connection. KSEs > preserve this connection. > > This typically means that, if you are attempting to use multiple > threads to unfairly compete for quantum, you will have to follow > the scheduler priority rules instead (many threads programmers > use threads in an attempt to subvert the scheduler policy without > resorting to increased priviledges; this is wrong). > > So your examples are all workable, merely by providing multiple > user space threads. > > > On Mon, 20 Nov 2000, Julian Elischer wrote: > > > A KSEG can only have as a maximum N KSEs associated with it, where N is > > > the number of processors, (unless artificially reduced by a lower > > > concurency declaration). (you said this but only indirectly). In > > > general, KSEs are each assigned to a processor. They do not in general > > > move between processors unless some explicit adjustment is being > > > made(*), and as a general rule, two KSEs will not be assigned to the > > > same processor. (in some transitional moments this may be allowed to > > > briefly happen) This in general if you run a KSEC on the same KSE it was > > > run on last time, you should be on the same processor, > > > (and get any affinity advantages that might exist). > > I really, really disagree with Julian's statement about not > assigning multiple KSEs to the same processor. There are > perfectly valid loading reasons (e.g. two KSEs that each take > 30% of the CPU, cooperating, with one CPU with a process that > takse 90% of the CPU, while the other CPU is only at 60% > utilization, etc.). NOT within the same KSEG... don't forget that to some extent the amount of CPU each KSE will get will depend on how much work it has.. hopefully the KSEs with 30% loads will have done 'yields'. > > There is also the PTHREAD_SCOPE_SYSTEM scheduling; one can > easily conceive of a multithreading application, where one thread > in the total list of threads needs to run with a real time > priority to insure rapid interacative response, with metered > intervals. One example would be a DVD player, where the > rendering needs to occur at fixed intervals with no latency, > whereas the fuffer-refill from the DVDROM, and the control > functons for the program, overall, can run in normal priority > threads. This is ONE KSE PER CPU PER KSEG...... you can have several KSE's competing for a processor. put them in differnt KSEGs. > > So I think there is a good argument for needing to support in > the kernel the idea of multiple KSEs on a single processor; I > understand Julian's anxiety about what this could do to the > complexity of the sleep queues, but with respect to everyone, > if the task's too complex, then stay out of the kernel (it's > not too complex for Julian, it's just I don't think that the > kernel should have to be written on the computer science > equivalent of a 6th grade reading leveli: if it can't be > understood by everyone, too bad: most people couldn't tell > you how the ignition system in their car works, either). you misunderstood my comment > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 23:54:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 6C40037B479; Mon, 20 Nov 2000 23:54:20 -0800 (PST) Received: from pretoria-36.budapest.interware.hu ([195.70.53.100] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13y8Fu-0001sg-00; Tue, 21 Nov 2000 08:54:19 +0100 Message-ID: <3A1A2A26.4CF0B849@elischer.org> Date: Mon, 20 Nov 2000 23:54:14 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG CC's trimmed, which group should stay? SMP or ARCH? Daniel Eischen wrote: > > > With the exception of where the thread > scheduler (UTS hereafter) allocates/requests one KSEG with > exactly one KSE. there is no reason why ANY KSEG need sto be limitted to one KSE by the kernel unless there is only one CPU. The PTHREAD_SCOPE_PROCESS, KSEG may have one or more KSEs assigned to it depending on whether the UTS wants to create more or not.... Thinking about what Terry said, I guess you could have M>N (M KSEs, N CPUs) in a KSEG, but I don't think it would be useful to do so. > > > One gross hack might be to limit the number of total KSEs to > > the number of permitted child processes for a given process, > > but I'd hesitate to encourage people to use the not generally > > exposed and non (POSIX) standard interfaces that would be > > needed for a process to try to do this automatically. > > You have to be careful with terminology. If we're going by > what Jason has defined in his paper, the KSEG is the entity > that has the quantum, not the KSE. So the KSEGs would be > limited to the permitted number of child processes. yes, but that gives the ability to use M times as much CPU as a nonthreaded process. > > If you want to have a separate quantum for each KSE, then > you can probably eliminate the KSEG. I've made this comment > also. It's possible that we may be able to do so, but not yet.. > > -- > Dan Eischen -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 20 23:56:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 65A2237B4C5; Mon, 20 Nov 2000 23:56:19 -0800 (PST) Received: from pretoria-36.budapest.interware.hu ([195.70.53.100] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13y8Hq-0001zC-00; Tue, 21 Nov 2000 08:56:18 +0100 Message-ID: <3A1A2A9D.BA6A8943@elischer.org> Date: Mon, 20 Nov 2000 23:56:13 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > We have an application that has very similar needs. Right now > we use Solaris, with some threads in RT and some not in RT. > I intend on making this work in FreeBSD also. that's what KSEGs are for... > > -- > Dan Eischen > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 3:59:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 7FDFF37B4C5; Tue, 21 Nov 2000 03:59:46 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id GAA13723; Tue, 21 Nov 2000 06:59:22 -0500 (EST) Date: Tue, 21 Nov 2000 06:59:22 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: Scott Hess , jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments In-Reply-To: <3A1A25C6.99B1B8F3@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 20 Nov 2000, Julian Elischer wrote: > Daniel Eischen wrote: > > > > > With 2 CPUs, you could have 2 KSEs within the KSEG. Nothing changes > > except that the KSEG workload is spread across 2 KSEs running on > > different CPUs. The quantum for the KSEG, regardless of whether > > there are 1 or more KSEs associated with it, remains the same > > (I would advocate a separate quantum in this case, but I think > > I'm outvoted on that front). > > not entirely > I think a process using two KSEs in a KSEG should be charged for 2. I agree if each KSE gets its own quantum. The way Jason explained it to me (in the case that the KSEG has the quantum), is that if 2 KSEs (in the same KSEG) run concurrently on 2 CPUs, then they would run for 1 quantum each. But the resource usage in the KSEG would be incremented by 2 quantum. > > This is all for PTHREAD_SCOPE_PROCESS threads. PTHREAD_SCOPE_SYSTEM > > threads will be bound to their own KSEG with one KSE. These will > > act more like LinuxThreads; when one of these threads block in > > the kernel, another one will not be executed (because there are no > > other threads allocated for that KSEG/KSE by the threads library). > > well, it WILL do the upcall but the UTS will respond with > "No new thread to schedule, please yield" Yes, exactly because the kernel doesn't know which KSEG is scope process and which KSEGs are scope system. I suppose the kernel could easily know, but there's no reason for it to care. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 4:29:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B417337B4C5 for ; Tue, 21 Nov 2000 04:29:42 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA17573; Tue, 21 Nov 2000 07:29:19 -0500 (EST) Date: Tue, 21 Nov 2000 07:29:19 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments In-Reply-To: <3A1A2A26.4CF0B849@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 20 Nov 2000, Julian Elischer wrote: > CC's trimmed, > > which group should stay? SMP or ARCH? I've stripped SMP. KSEs were first brought up under -arch, and for the most part, we'd be having the same discussion without SMP availability. Feel free to change it to -smp if you wish. > Daniel Eischen wrote: > > > > With the exception of where the thread > > scheduler (UTS hereafter) allocates/requests one KSEG with > > exactly one KSE. > > there is no reason why ANY KSEG need sto be limitted to one KSE > by the kernel unless there is only one CPU. > The PTHREAD_SCOPE_PROCESS, KSEG may have one or more KSEs > assigned to it depending > on whether the UTS wants to create more or not.... It's been (mostly) decided that a PTHREAD_SCOPE_PROCESS thread runs by itself in it's own KSEG and KSE. This is what I am referring to above. And I'm not saying the kernel limits it to 1 KSE, the UTS does this because it is running a scope system thread and doesn't want another KSE. > > You have to be careful with terminology. If we're going by > > what Jason has defined in his paper, the KSEG is the entity > > that has the quantum, not the KSE. So the KSEGs would be > > limited to the permitted number of child processes. > > yes, but that gives the ability to use M times as much CPU as a > nonthreaded process. Whatever. Create yet another resource limit then. I think we all know that there has to be some limit. Exactly what the limit is, can be decided later. > > If you want to have a separate quantum for each KSE, then > > you can probably eliminate the KSEG. I've made this comment > > also. > > It's possible that we may be able to do so, but > not yet.. I'm willing to work with it either way, but it could make it easier from the kernels point of view if you did get rid of the KSEG. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 9: 4:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id EEF8837B4C5; Tue, 21 Nov 2000 09:04:26 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA38946; Tue, 21 Nov 2000 10:04:25 -0700 (MST) (envelope-from ken) Date: Tue, 21 Nov 2000 10:04:25 -0700 From: "Kenneth D. Merry" To: net@FreeBSD.org Subject: new zero copy sockets and NFS snapshot Message-ID: <20001121100425.A38926@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early November 20th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Questions, comments and feedback are welcome. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - The fix to the "localhost panic" problem has been revamped. We now use a new external mbuf type, EXT_DISPOSABLE, to indicate that the external mbuf payload may be page-flipped or otherwise discarded. Instead of attempting to page flip any pages that meet the size and alignment criteria, we now only page flip external mbufs marked as disposable. (Thanks to Drew Gallatin for suggesting this approach.) - The decision process on when to use vm_uiomove() versus vm_pgmoveco() in uiomoveco() has been revamped somewhat. We no longer panic in any case. Anything that isn't handled by vm_pgmoveco() (according to the page flip criteria described above) is passed to vm_uiomove(). - uiomoveco() has been reorganized somewhat, with some of the functionality split out into a subfunction. There are no known problems with the code. If anyone wants to challenge that, I'll gladly accept bug reports, code comments, etc. :) For those of you who missed the previous messages about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Zero copy send and receive code, written by Drew Gallatin . - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. The Alteon header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which kindly agreed to let me release the code. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 10:25:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id AD36A37B4C5; Tue, 21 Nov 2000 10:25:31 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id LAA24260; Tue, 21 Nov 2000 11:26:07 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAIbaq_U; Tue Nov 21 11:25:40 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA27595; Tue, 21 Nov 2000 11:24:59 -0700 (MST) From: Terry Lambert Message-Id: <200011211824.LAA27595@usr08.primenet.com> Subject: Re: Threads (KSE etc) comments To: julian@elischer.org (Julian Elischer) Date: Tue, 21 Nov 2000 18:24:59 +0000 (GMT) Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG In-Reply-To: <3A1A2A26.4CF0B849@elischer.org> from "Julian Elischer" at Nov 20, 2000 11:54:14 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > CC's trimmed, > > which group should stay? SMP or ARCH? ARCH is chartered for the discussion, SMP is where the work is actually geting done. I think that's the reason for the original poster to cross-post. I'll let clearer heads prevail by picking where to sent their response. > there is no reason why ANY KSEG need sto be limitted to one KSE > by the kernel unless there is only one CPU. > The PTHREAD_SCOPE_PROCESS, KSEG may have one or more KSEs > assigned to it depending > on whether the UTS wants to create more or not.... > > Thinking about what Terry said, I guess you could have M>N > (M KSEs, N CPUs) in a KSEG, but I don't think it would be > useful to do so. It lets me have M simultaneous blocking operations outstanding; it's only not useful in the context of KSEGs. I guess we could arrange it this way: (1 KSE, 1 KSEG), (M KSEGs, N CPUs) This should make it more obvious: I want M quanta from N CPUs. Or in other words, I want to compete as M porcesses on this N CPU system. The reason for this is to allow me to control my own interleave; for example, if we look at the "team" or "ddd" programs, both of which use interleaved I/O using multiple processes to improve overall throughput, we see an application where I _do not_ want 2 quanta for 3 threads, with 2 of the threads bound to only one of the quanta: doing that will lose me 25% of my throughput. If you want to visualize the scheduling order, think of a three element braid (braids are neat: the simplest is a three element, and you can think of it as a graph of FIFO queue, two elements at a time). If there is equal work, then the work on each of two elements is going to complete in alternating order, which means that if you have a third element waiting, it will be alternately assigned (ideally; KSEGs break this). I think that perhaps the best use of threading is to try to interleave I/O to ensure against I/O binding. KSEGs seem to be designed with the idea that the threaded application is CPU, not I/O bound, which is where I think the mistake lies. > > > One gross hack might be to limit the number of total KSEs to > > > the number of permitted child processes for a given process, > > > but I'd hesitate to encourage people to use the not generally > > > exposed and non (POSIX) standard interfaces that would be > > > needed for a process to try to do this automatically. > > > > You have to be careful with terminology. If we're going by > > what Jason has defined in his paper, the KSEG is the entity > > that has the quantum, not the KSE. So the KSEGs would be > > limited to the permitted number of child processes. > > yes, but that gives the ability to use M times as much CPU as a > nonthreaded process. If you won't give it to me, I'll just take it, instead, either by using rfork() and a shared memory segment for my global data, which gets me the equivalenet of a threaded environment, for all practical purposes, or I'll just fork() and run multiple instances of myself. Either way, you don't get to tell me not to compete as multiple processes, and I can throw a KSEG based policy out the window, without needing your permission to do it. Worse, there is additional context switch overhead introduced by this (the same reason Linux kernel threads are a bad idea), and everyone gets to pay the penalty for my application. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 10:44: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from spammie.svbug.com (mg128-177.ricochet.net [204.179.128.177]) by hub.freebsd.org (Postfix) with ESMTP id E79EF37B4D7; Tue, 21 Nov 2000 10:43:55 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id KAA00298; Tue, 21 Nov 2000 10:43:07 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200011211843.KAA00298@spammie.svbug.com> Date: Tue, 21 Nov 2000 10:43:05 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: New security policy for FreeBSD 3.x To: security-officer@FreeBSD.ORG Cc: arch@FreeBSD.ORG In-Reply-To: <20001120035146.0020937B479@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please note I've cc'd to arch. Could you make your comments there? On 19 Nov, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > The FreeBSD Security Officer would like to announce a change in policy > regarding security support for the FreeBSD 3.x branch. > > Due to the frequent difficulties encountered in fixing the old code > contained in FreeBSD 3.x, we will no longer be requiring security > problems to be fixed in that branch prior to the release of an > advisory that also pertains to FreeBSD 4.x. In recent months this > requirement has led to delays in the release of advisories, which > negatively impacts users of the current FreeBSD release branch > (FreeBSD 4.x). > Could you clarify exactly what you are saying? It's not clear. Perhaps a chart might help. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 13: 1:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from spammie.svbug.com (mg128-177.ricochet.net [204.179.128.177]) by hub.freebsd.org (Postfix) with ESMTP id A923C37B4CF for ; Tue, 21 Nov 2000 13:01:44 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id NAA00440 for ; Tue, 21 Nov 2000 13:01:00 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200011212101.NAA00440@spammie.svbug.com> Date: Tue, 21 Nov 2000 13:00:57 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Does this sound good? (Fwd: Re: passwd file update functions) To: arch@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This went throught the mailing list for netbsd. Would such an idea be good for FreeBSD? ------ Forwarded message ------ From: Jaromír Dolecek Subject: Re: passwd file update functions Date: Mon, 20 Nov 2000 16:36:00 +0100 (CET) To: Matthias Scheler Cc: tech-userlevel@netbsd.org Matthias Scheler wrote: > the passwd file update functions in "libutil" don't support using a > directory other than "/etc" for the password database. I would like > to add a new function "pw_prefix(3)" which can be used to set the > prefix. This function could e.g. be used to enhance "vipw" and > "rpc.yppasswdd" to work with directories != "/etc". > > Opinions? Sounds good. Jaromir -- Jaromir Dolecek http://www.ics.muni.cz/~dolecek/ @@@@ Wanna a real operating system ? Go and get NetBSD, damn! @@@@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 13: 8:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 2A6BE37B4CF for ; Tue, 21 Nov 2000 13:08:44 -0800 (PST) Received: from mogadishu-42.budapest.interware.hu ([195.70.52.106] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13yKeg-00070D-00; Tue, 21 Nov 2000 22:08:42 +0100 Message-ID: <3A1AE456.9F883FE3@elischer.org> Date: Tue, 21 Nov 2000 13:08:38 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: opentrax@email.com Cc: arch@freebsd.org Subject: Re: Does this sound good? (Fwd: Re: passwd file update functions) References: <200011212101.NAA00440@spammie.svbug.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG opentrax@email.com wrote: > > This went throught the mailing list for netbsd. > Would such an idea be good for FreeBSD? > > ------ Forwarded message ------ > From: Jaromír Dolecek > Subject: Re: passwd file update functions > Date: Mon, 20 Nov 2000 16:36:00 +0100 (CET) > To: Matthias Scheler > Cc: tech-userlevel@netbsd.org > > Matthias Scheler wrote: > > the passwd file update functions in "libutil" don't support using a > > directory other than "/etc" for the password database. I would like > > to add a new function "pw_prefix(3)" which can be used to set the > > prefix. This function could e.g. be used to enhance "vipw" and > > "rpc.yppasswdd" to work with directories != "/etc". that would be good for Whistle, though by now we have (well, they have) workarounds for the fact that / is read-only.. mostly symlinks. > > > > Opinions? > > Sounds good. > > Jaromir > -- > Jaromir Dolecek http://www.ics.muni.cz/~dolecek/ > @@@@ Wanna a real operating system ? Go and get NetBSD, damn! @@@@ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 13:23:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BF69137B4CF; Tue, 21 Nov 2000 13:23:22 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA09525; Tue, 21 Nov 2000 16:23:01 -0500 (EST) Date: Tue, 21 Nov 2000 16:23:00 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Julian Elischer , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments In-Reply-To: <200011211824.LAA27595@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, Terry Lambert wrote: > > yes, but that gives the ability to use M times as much CPU as a > > nonthreaded process. > > If you won't give it to me, I'll just take it, instead, either > by using rfork() and a shared memory segment for my global data, > which gets me the equivalenet of a threaded environment, for all > practical purposes, or I'll just fork() and run multiple instances > of myself. Either way, you don't get to tell me not to compete > as multiple processes, and I can throw a KSEG based policy out the > window, without needing your permission to do it. Worse, there > is additional context switch overhead introduced by this (the > same reason Linux kernel threads are a bad idea), and everyone > gets to pay the penalty for my application. I have to agree with Terry. You can't dictate what application writers will do. If they want more CPU and they can't get it with the threading model we provide, then they will get it another way. Limiting PTHREAD_SCOPE_PROCESS threads to 1 KSEG with only 1 quantum doesn't stop someone from [r]fork()'ing to get more CPU. Let's admit that this is what some applications will want to do and allow them to do it within our threading model. No, we won't do it by default, but we can provide simple hooks to allow an application to request more "CPU reservations" (a KSEG under the current definition). Note that I am only talking about scope process threads. Scope system threads are bound to their own KSEG/KSE pair. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 13:28:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alpha.netaccess.on.ca (alpha.netaccess.on.ca [199.243.225.10]) by hub.freebsd.org (Postfix) with ESMTP id 7502237B479; Tue, 21 Nov 2000 13:28:52 -0800 (PST) Received: from schizo.controlq.com (dial162.nas.net [207.176.144.162]) by alpha.netaccess.on.ca (8.9.0/8.9.0) with ESMTP id QAA11149; Tue, 21 Nov 2000 16:28:50 -0500 (EST) Date: Tue, 21 Nov 2000 16:34:57 -0500 (EST) From: "Robert S. Sciuk" Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This may be out of line, but in line with the cpu allocation question, is there (will there be) a mechanism for processor affinity determination, and changes?? This is important wrt cache coherency and producer/consumer type processes/threads. Just wondering. On Tue, 21 Nov 2000, Daniel Eischen wrote: > On Tue, 21 Nov 2000, Terry Lambert wrote: > > > yes, but that gives the ability to use M times as much CPU as a > > > nonthreaded process. > > > > If you won't give it to me, I'll just take it, instead, either > > by using rfork() and a shared memory segment for my global data, > > which gets me the equivalenet of a threaded environment, for all > > practical purposes, or I'll just fork() and run multiple instances > > of myself. Either way, you don't get to tell me not to compete > > as multiple processes, and I can throw a KSEG based policy out the > > window, without needing your permission to do it. Worse, there > > is additional context switch overhead introduced by this (the > > same reason Linux kernel threads are a bad idea), and everyone > > gets to pay the penalty for my application. > > I have to agree with Terry. You can't dictate what application > writers will do. If they want more CPU and they can't get it > with the threading model we provide, then they will get it > another way. Limiting PTHREAD_SCOPE_PROCESS threads to 1 KSEG > with only 1 quantum doesn't stop someone from [r]fork()'ing > to get more CPU. > > Let's admit that this is what some applications will want to > do and allow them to do it within our threading model. No, > we won't do it by default, but we can provide simple hooks to > allow an application to request more "CPU reservations" > (a KSEG under the current definition). > > Note that I am only talking about scope process threads. > Scope system threads are bound to their own KSEG/KSE pair. > > -- > Dan Eischen > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Robert S. Sciuk http://www.controlq.com 1032 Howard Rd. RR#2 Control-Q Research tel: 905.632.2466 Burlington, Ont. rob@controlq.com fax: 905.632.7417 Canada, L7R 3X5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 15:52:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6103337B65E for ; Tue, 21 Nov 2000 15:52:20 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA00727; Tue, 21 Nov 2000 18:52:00 -0500 (EST) Date: Tue, 21 Nov 2000 18:51:59 -0500 (EST) From: Daniel Eischen To: arch@freebsd.org Subject: Thread-specific data and KSEs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm going to start working on the user-side of the new threads library. I need to be able to quickly get at the current KSE (or perhaps KSEG). Can we define a register on each architecture that should not be used by FreeBSD ABI compliant applications? The register doesn't have to be 32 bits or larger, just large enough to hold the maximum number of KSEs (or KSEGs). -- "Some may prefer open source, but me, I prefer open bar." -- Spencer F. Katt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 15:55:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id EE2F737B4CF; Tue, 21 Nov 2000 15:55:33 -0800 (PST) Received: from mogadishu-42.budapest.interware.hu ([195.70.52.106] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13yNFx-0002On-00; Wed, 22 Nov 2000 00:55:21 +0100 Message-ID: <3A1B0B64.6D694248@elischer.org> Date: Tue, 21 Nov 2000 15:55:16 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@FreeBSD.ORG Cc: smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Note to all on FreeBSD-SMP.. this is to ARCH, and CC'd to SMP I'll trim SMP next time around so if you are reading this in SMP and are not on 'arch'...... Daniel Eischen wrote: > > On Tue, 21 Nov 2000, Terry Lambert wrote: > > > yes, but that gives the ability to use M times as much CPU as a > > > nonthreaded process. > > > > If you won't give it to me, I'll just take it, instead, either > > by using rfork() and a shared memory segment for my global data, > > which gets me the equivalenet of a threaded environment, for all > > practical purposes, or I'll just fork() and run multiple instances > > of myself. Either way, you don't get to tell me not to compete > > as multiple processes, and I can throw a KSEG based policy out the > > window, without needing your permission to do it. Worse, there > > is additional context switch overhead introduced by this (the > > same reason Linux kernel threads are a bad idea), and everyone > > gets to pay the penalty for my application. > > I have to agree with Terry. You can't dictate what application > writers will do. If they want more CPU and they can't get it > with the threading model we provide, then they will get it > another way. Limiting PTHREAD_SCOPE_PROCESS threads to 1 KSEG > with only 1 quantum doesn't stop someone from [r]fork()'ing > to get more CPU. At this stage I'm having the following thoughts.. 1/ I think we've almost talked ourselves out of the need for a KSEG. 2/ I don't want to actually say that until I've thought about it a bit.. there were some REALLY GOOD REASONS for it before, I just can't think what they were. I'll probably remember at 3AM this morning while I'm mostly asleep. My remaining use for KSEGs is for housekeeping: 3/ My KSEG thought was: The user can take as many quanta as he wants by having many KSEGs. If he uses default actions and simply fires off a lot of threads, he gets N quanta, per 'round-robin cycle, where N is the number of CPUs, because by default the threads package only fires up a max of N KSEs to run the threads on in each KSEG. The KSEG is an 'official' way for him to be more greedy. but he has to ask for it.. One KSEG gives a single timeslot per round-robin, on each CPU. but KSEs in the same KSEG don't compete with each other in the KSEG. 4/ I am not sure that #3 is completely useful these days either, I'm thinking about it. 5/ it's possible that if KSEs in the same KSEG can never be on the same CPU then they can never 'pre-empt' each other. This means that locking between the UTS instances in the same KSE can predict that locks on structures held private within the KSE can never 'block', but will always 'spin-out' in a short time (assuming the UTS is written correctly). This means that (for example) threads assigned to the same KSEG can be migrated around easily within the KSEG with very simple locking. If there are two KSE's in teh same KSEG on teh same CPU, there is always the danger that one may pre-empt the other while it holds a lock on a KSEG internal structure, and then we might deadlock. (this thought is also rather vague) Basically, KSE's are to provide concurrency across processors, where KSEGs are to provide competition in the scheduler. I see the two as being orthogonal. KSEGs may go away, or may be simply a 'virtual element' that never actually exists. but I still see the use of confining 'normal threads' to some bounded box. The fact that we give you the ability to make more boxes at you leasure shouldn't detract from the usefulness of the box. Scheduling within the box (and migration therin) needs to be fast and may happen very frequently. Moving between boxes is probably less frequent. For that reason I like having the boxes well defined in a way that ensures that they are well behaved. making each box contain only one KSE from each CPU allows as much concurrency as you can get, yet makes sure that we don't have to deal with KSEs tripping over each other. I think it will make the use of simple (tiny) spinlocks the most that will be needed for such things as process migration within the box. If you start having KSEs (there is one UTS 'incarnation' per KSE) tripping over each other's CPUs it starts to get more complicated. Having said that, I'm still thinking about whether KSEGs can go away. > Let's admit that this is what some applications will want to > do and allow them to do it within our threading model. No, > we won't do it by default, but we can provide simple hooks to > allow an application to request more "CPU reservations" > (a KSEG under the current definition). exactly We allow them to be greedy. but we make them do slightly more work for it. At least they KNOW they are being greedy. > > Note that I am only talking about scope process threads. > Scope system threads are bound to their own KSEG/KSE pair. KSEG/KSEs If A SCOPE_SYSTEM thread creates a new thread, that thread competes with it on however many KSEs it has, within it's KSEG. > > -- > Dan Eischen Was my explanation of how KSEs communicate with the UTS clear enough? It's hard to decide that for your own writing.... -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 15:57:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id EB85037B4CF for ; Tue, 21 Nov 2000 15:57:38 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eALNutZ32181; Tue, 21 Nov 2000 17:56:55 -0600 (CST) (envelope-from jlemon) Date: Tue, 21 Nov 2000 17:56:55 -0600 From: Jonathan Lemon To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs Message-ID: <20001121175655.T19895@prism.flugsvamp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: > I'm going to start working on the user-side of the new threads > library. I need to be able to quickly get at the current KSE > (or perhaps KSEG). Can we define a register on each architecture > that should not be used by FreeBSD ABI compliant applications? > The register doesn't have to be 32 bits or larger, just large > enough to hold the maximum number of KSEs (or KSEGs). Um. On a i386 I'm not sure this will be practical, there aren't a whole lot of architecturally visible registers for use by the application. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 16: 7:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id A842C37B4CF for ; Tue, 21 Nov 2000 16:07:54 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAM07f029162; Tue, 21 Nov 2000 16:07:41 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001121175655.T19895@prism.flugsvamp.com> Date: Tue, 21 Nov 2000 16:07:50 -0800 (PST) From: John Baldwin To: Jonathan Lemon Subject: Re: Thread-specific data and KSEs Cc: arch@FreeBSD.org, Daniel Eischen Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21-Nov-00 Jonathan Lemon wrote: > On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: >> I'm going to start working on the user-side of the new threads >> library. I need to be able to quickly get at the current KSE >> (or perhaps KSEG). Can we define a register on each architecture >> that should not be used by FreeBSD ABI compliant applications? >> The register doesn't have to be 32 bits or larger, just large >> enough to hold the maximum number of KSEs (or KSEGs). > > Um. On a i386 I'm not sure this will be practical, there aren't > a whole lot of architecturally visible registers for use by the > application. Agreed. Just use a regulare per-CPU data variable the same way that 'curproc' is implemented right now. > -- > Jonathan -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 16:52:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from io.yi.org (h24-69-199-88.gv.shawcable.net [24.69.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 57C9737B4CF; Tue, 21 Nov 2000 16:52:09 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 95369BA7A; Tue, 21 Nov 2000 16:52:08 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: John Baldwin Cc: Jonathan Lemon , arch@FreeBSD.ORG, Daniel Eischen Subject: Re: Thread-specific data and KSEs In-Reply-To: Message from John Baldwin of "Tue, 21 Nov 2000 16:07:50 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 16:52:08 -0800 From: Jake Burkholder Message-Id: <20001122005208.95369BA7A@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On 21-Nov-00 Jonathan Lemon wrote: > > On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: > >> I'm going to start working on the user-side of the new threads > >> library. I need to be able to quickly get at the current KSE > >> (or perhaps KSEG). Can we define a register on each architecture > >> that should not be used by FreeBSD ABI compliant applications? > >> The register doesn't have to be 32 bits or larger, just large > >> enough to hold the maximum number of KSEs (or KSEGs). > > > > Um. On a i386 I'm not sure this will be practical, there aren't > > a whole lot of architecturally visible registers for use by the > > application. > > Agreed. Just use a regulare per-CPU data variable the same way that 'curproc' > is implemented right now. > Uhh, the way curproc is implemented now is basically what he's talking about. Its addressable through the %fs register, but I don't know how you'd set this up to work from userland. Can you even change the segment registers in user mode? My suggestion would be to have the stacks aligned to some power of 2 boundary and put your per-thread pointer at the top of the stack. Then you can get at it like this: ((stack pointer + (stack size)) & ~(stack size - 1)) - sizeof(void *) and you don't need to know which cpu you're on. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 16:52:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id D08FD37B4CF for ; Tue, 21 Nov 2000 16:52:14 -0800 (PST) Received: from mogadishu-42.budapest.interware.hu ([195.70.52.106] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13yO8z-0005gP-00; Wed, 22 Nov 2000 01:52:13 +0100 Message-ID: <3A1B18B8.37DDA213@elischer.org> Date: Tue, 21 Nov 2000 16:52:08 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jonathan Lemon Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs References: <20001121175655.T19895@prism.flugsvamp.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Lemon wrote: > > On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: > > I'm going to start working on the user-side of the new threads > > library. I need to be able to quickly get at the current KSE > > (or perhaps KSEG). Can we define a register on each architecture > > that should not be used by FreeBSD ABI compliant applications? > > The register doesn't have to be 32 bits or larger, just large > > enough to hold the maximum number of KSEs (or KSEGs). > > Um. On a i386 I'm not sure this will be practical, there aren't > a whole lot of architecturally visible registers for use by the > application. As I just mentionned in other email, the beauty of the KSE scheme is that the kernel keeps track of it for you because the upcalls come back with stacks in different places, so if you safe the 'current thread' on that stack, you have it where you need it. > -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 17: 0: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 4C10B37B4CF for ; Tue, 21 Nov 2000 16:59:57 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAM0xm063538; Tue, 21 Nov 2000 16:59:48 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001122005208.95369BA7A@io.yi.org> Date: Tue, 21 Nov 2000 16:59:57 -0800 (PST) From: John Baldwin To: Jake Burkholder Subject: Re: Thread-specific data and KSEs Cc: Daniel Eischen , arch@FreeBSD.org, Jonathan Lemon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Jake Burkholder wrote: >> >> On 21-Nov-00 Jonathan Lemon wrote: >> > On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: >> >> I'm going to start working on the user-side of the new threads >> >> library. I need to be able to quickly get at the current KSE >> >> (or perhaps KSEG). Can we define a register on each architecture >> >> that should not be used by FreeBSD ABI compliant applications? >> >> The register doesn't have to be 32 bits or larger, just large >> >> enough to hold the maximum number of KSEs (or KSEGs). >> > >> > Um. On a i386 I'm not sure this will be practical, there aren't >> > a whole lot of architecturally visible registers for use by the >> > application. >> >> Agreed. Just use a regulare per-CPU data variable the same way that >> 'curproc' >> is implemented right now. >> > > Uhh, the way curproc is implemented now is basically what he's talking > about. Its addressable through the %fs register, but I don't know > how you'd set this up to work from userland. Can you even change the > segment registers in user mode? Well, sort of. I think his take would be more along the lines of storing hte KSE number in %eax or %gs. Actually, %gs _might_ be feasible. Rather, having %gs point to thread-local storage that both userland and kernel can get at might be useful. You can change the segment registers from user mode if you want, but that doesn't really buy you much. > My suggestion would be to have the stacks aligned to some power > of 2 boundary and put your per-thread pointer at the top of the > stack. Then you can get at it like this: > > ((stack pointer + (stack size)) & ~(stack size - 1)) - sizeof(void *) > > and you don't need to know which cpu you're on. Hmmmm.... -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 17: 1:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CF4AD37B4D7 for ; Tue, 21 Nov 2000 17:01:20 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id TAA09651; Tue, 21 Nov 2000 19:58:36 -0500 (EST) Date: Tue, 21 Nov 2000 19:58:36 -0500 (EST) From: Daniel Eischen To: Jonathan Lemon Cc: arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: <20001121175655.T19895@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, Jonathan Lemon wrote: > On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: > > I'm going to start working on the user-side of the new threads > > library. I need to be able to quickly get at the current KSE > > (or perhaps KSEG). Can we define a register on each architecture > > that should not be used by FreeBSD ABI compliant applications? > > The register doesn't have to be 32 bits or larger, just large > > enough to hold the maximum number of KSEs (or KSEGs). > > Um. On a i386 I'm not sure this will be practical, there aren't > a whole lot of architecturally visible registers for use by the > application. Why can't we use a segment register? -- "Some may prefer open source, but me, I prefer open bar." -- Spencer F. Katt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 17:10:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id BF20637B4C5 for ; Tue, 21 Nov 2000 17:10:34 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAM1AQ082015; Tue, 21 Nov 2000 17:10:26 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 21 Nov 2000 17:10:36 -0800 (PST) From: John Baldwin To: Daniel Eischen Subject: Re: Thread-specific data and KSEs Cc: arch@FreeBSD.org, Jonathan Lemon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Daniel Eischen wrote: > On Tue, 21 Nov 2000, Jonathan Lemon wrote: >> On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: >> > I'm going to start working on the user-side of the new threads >> > library. I need to be able to quickly get at the current KSE >> > (or perhaps KSEG). Can we define a register on each architecture >> > that should not be used by FreeBSD ABI compliant applications? >> > The register doesn't have to be 32 bits or larger, just large >> > enough to hold the maximum number of KSEs (or KSEGs). >> >> Um. On a i386 I'm not sure this will be practical, there aren't >> a whole lot of architecturally visible registers for use by the >> application. > > Why can't we use a segment register? %cs = code segment and is taken %ds = data segment and is taken %es = not sure, but bet it isn't safe %ss = stack, taken %fs = per-CPU data %gs ? as I mentioned in my other message, this one might be useful for addressing a structure of thread-local variables much like %fs is used for per-CPU data. It also has value in that supposedly x86-64 (aka k64) has both %fs and %gs, but no other seg regs. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 17:13:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9419D37B479; Tue, 21 Nov 2000 17:13:28 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id UAA11784; Tue, 21 Nov 2000 20:13:07 -0500 (EST) Date: Tue, 21 Nov 2000 20:13:07 -0500 (EST) From: Daniel Eischen To: John Baldwin Cc: arch@FreeBSD.org, Jonathan Lemon Subject: Re: Thread-specific data and KSEs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, John Baldwin wrote: > > On 22-Nov-00 Daniel Eischen wrote: > > On Tue, 21 Nov 2000, Jonathan Lemon wrote: > >> On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: > >> > I'm going to start working on the user-side of the new threads > >> > library. I need to be able to quickly get at the current KSE > >> > (or perhaps KSEG). Can we define a register on each architecture > >> > that should not be used by FreeBSD ABI compliant applications? > >> > The register doesn't have to be 32 bits or larger, just large > >> > enough to hold the maximum number of KSEs (or KSEGs). > >> > >> Um. On a i386 I'm not sure this will be practical, there aren't > >> a whole lot of architecturally visible registers for use by the > >> application. > > > > Why can't we use a segment register? > > %cs = code segment and is taken > %ds = data segment and is taken > %es = not sure, but bet it isn't safe > %ss = stack, taken > %fs = per-CPU data Isn't this kernel-only? > %gs ? as I mentioned in my other message, this one might be useful for > addressing a structure of thread-local variables much like %fs is used for > per-CPU data. It also has value in that supposedly x86-64 (aka k64) has both > %fs and %gs, but no other seg regs. All I need is one. -- "Some may prefer open source, but me, I prefer open bar." -- Spencer F. Katt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 17:19:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 145AF37B4C5 for ; Tue, 21 Nov 2000 17:19:28 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAM1JD006163; Tue, 21 Nov 2000 17:19:13 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 21 Nov 2000 17:19:23 -0800 (PST) From: John Baldwin To: Daniel Eischen Subject: Re: Thread-specific data and KSEs Cc: Jonathan Lemon , arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Daniel Eischen wrote: > On Tue, 21 Nov 2000, John Baldwin wrote: >> >> On 22-Nov-00 Daniel Eischen wrote: >> > On Tue, 21 Nov 2000, Jonathan Lemon wrote: >> >> On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: >> >> > I'm going to start working on the user-side of the new threads >> >> > library. I need to be able to quickly get at the current KSE >> >> > (or perhaps KSEG). Can we define a register on each architecture >> >> > that should not be used by FreeBSD ABI compliant applications? >> >> > The register doesn't have to be 32 bits or larger, just large >> >> > enough to hold the maximum number of KSEs (or KSEGs). >> >> >> >> Um. On a i386 I'm not sure this will be practical, there aren't >> >> a whole lot of architecturally visible registers for use by the >> >> application. >> > >> > Why can't we use a segment register? >> >> %cs = code segment and is taken >> %ds = data segment and is taken >> %es = not sure, but bet it isn't safe >> %ss = stack, taken >> %fs = per-CPU data > > Isn't this kernel-only? I think so, but I would prefer that we use %gs if we go this route so that the same mechanism can be used both in and out of the kernel. If that makes sense. >> %gs ? as I mentioned in my other message, this one might be useful for >> addressing a structure of thread-local variables much like %fs is used for >> per-CPU data. It also has value in that supposedly x86-64 (aka k64) has >> both >> %fs and %gs, but no other seg regs. > > All I need is one. Well, %gs would cover x86 and k64. I think ia64 has several application registers that are available for OS use and we could steal one of those. I'm not sure about the alpha though. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 17:51: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1AD7F37B4C5; Tue, 21 Nov 2000 17:51:05 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAM1p0E23357; Tue, 21 Nov 2000 17:51:00 -0800 (PST) Date: Tue, 21 Nov 2000 17:51:00 -0800 From: Alfred Perlstein To: John Baldwin Cc: Daniel Eischen , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs Message-ID: <20001121175100.B18037@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Tue, Nov 21, 2000 at 05:19:23PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [001121 17:19] wrote: > > On 22-Nov-00 Daniel Eischen wrote: > >> %gs ? as I mentioned in my other message, this one might be useful for > >> addressing a structure of thread-local variables much like %fs is used for > >> per-CPU data. It also has value in that supposedly x86-64 (aka k64) has > >> both > >> %fs and %gs, but no other seg regs. > > > > All I need is one. > > Well, %gs would cover x86 and k64. I think ia64 has several application > registers that are available for OS use and we could steal one of those. I'm > not sure about the alpha though. Don't more segment registers cause more overhead for context switches? Just wondering. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 17:57:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from io.yi.org (h24-69-199-88.gv.shawcable.net [24.69.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 3F16437B479; Tue, 21 Nov 2000 17:57:56 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id AF470BA7A; Tue, 21 Nov 2000 17:57:56 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: John Baldwin Cc: Daniel Eischen , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: Message from John Baldwin of "Tue, 21 Nov 2000 17:19:23 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 17:57:56 -0800 From: Jake Burkholder Message-Id: <20001122015756.AF470BA7A@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On 22-Nov-00 Daniel Eischen wrote: > > On Tue, 21 Nov 2000, John Baldwin wrote: > >> > >> On 22-Nov-00 Daniel Eischen wrote: > >> > On Tue, 21 Nov 2000, Jonathan Lemon wrote: > >> >> On Tue, Nov 21, 2000 at 06:51:59PM -0500, Daniel Eischen wrote: > >> >> > I'm going to start working on the user-side of the new threads > >> >> > library. I need to be able to quickly get at the current KSE > >> >> > (or perhaps KSEG). Can we define a register on each architecture > >> >> > that should not be used by FreeBSD ABI compliant applications? > >> >> > The register doesn't have to be 32 bits or larger, just large > >> >> > enough to hold the maximum number of KSEs (or KSEGs). > >> >> > >> >> Um. On a i386 I'm not sure this will be practical, there aren't > >> >> a whole lot of architecturally visible registers for use by the > >> >> application. > >> > > >> > Why can't we use a segment register? > >> > >> %cs = code segment and is taken > >> %ds = data segment and is taken > >> %es = not sure, but bet it isn't safe > >> %ss = stack, taken > >> %fs = per-CPU data > > > > Isn't this kernel-only? > > I think so, but I would prefer that we use %gs if we go this route so that the > same mechanism can be used both in and out of the kernel. If that makes sense. > > >> %gs ? as I mentioned in my other message, this one might be useful for > >> addressing a structure of thread-local variables much like %fs is used for > >> per-CPU data. It also has value in that supposedly x86-64 (aka k64) has > >> both > >> %fs and %gs, but no other seg regs. > > > > All I need is one. > > Well, %gs would cover x86 and k64. I think ia64 has several application > registers that are available for OS use and we could steal one of those. I'm > not sure about the alpha though. > Doug uses $8 (t7) on the alpha for the per-cpu data pointer, and r13 on ia64. Not that that means anything to me. alpha/inclue/globals.h: register struct globaldata *globalp __asm__("$8"); ia64/include/globals.h: register struct globaldata *globalp __asm__("r13"); Its not really relevant if they're the same in and out of the kernel cause the memory isn't addressable in both places anyway. > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 19:14:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8988337B4D7; Tue, 21 Nov 2000 19:14:29 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA27090; Tue, 21 Nov 2000 22:14:09 -0500 (EST) Date: Tue, 21 Nov 2000 22:14:09 -0500 (EST) From: Daniel Eischen To: John Baldwin Cc: Jonathan Lemon , arch@FreeBSD.org Subject: Re: Thread-specific data and KSEs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, John Baldwin wrote: > On 22-Nov-00 Daniel Eischen wrote: > > On Tue, 21 Nov 2000, John Baldwin wrote: > >> > >> On 22-Nov-00 Daniel Eischen wrote: > >> > Why can't we use a segment register? > >> > >> %cs = code segment and is taken > >> %ds = data segment and is taken > >> %es = not sure, but bet it isn't safe > >> %ss = stack, taken > >> %fs = per-CPU data > > > > Isn't this kernel-only? > > I think so, but I would prefer that we use %gs if we go this route so that the > same mechanism can be used both in and out of the kernel. If that makes sense. That's fine with me. > >> %gs ? as I mentioned in my other message, this one might be useful for > >> addressing a structure of thread-local variables much like %fs is used for > >> per-CPU data. It also has value in that supposedly x86-64 (aka k64) has > >> both > >> %fs and %gs, but no other seg regs. > > > > All I need is one. > > Well, %gs would cover x86 and k64. I think ia64 has several application > registers that are available for OS use and we could steal one of those. I'm > not sure about the alpha though. OK, I think we can use an S register. These are suppose to be call-safe, if I can believe sys/alpha/include/asm.h. Any alpha gurus care to respond? -- "Some folks are into open source, but me, I'm into open bar." -- Spencer F. Katt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 19:15:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id AF09137B479; Tue, 21 Nov 2000 19:15:50 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA27327; Tue, 21 Nov 2000 22:15:28 -0500 (EST) Date: Tue, 21 Nov 2000 22:15:28 -0500 (EST) From: Daniel Eischen To: Alfred Perlstein Cc: John Baldwin , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: <20001121175100.B18037@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, Alfred Perlstein wrote: > * John Baldwin [001121 17:19] wrote: > > > > On 22-Nov-00 Daniel Eischen wrote: > > >> %gs ? as I mentioned in my other message, this one might be useful for > > >> addressing a structure of thread-local variables much like %fs is used for > > >> per-CPU data. It also has value in that supposedly x86-64 (aka k64) has > > >> both > > >> %fs and %gs, but no other seg regs. > > > > > > All I need is one. > > > > Well, %gs would cover x86 and k64. I think ia64 has several application > > registers that are available for OS use and we could steal one of those. I'm > > not sure about the alpha though. > > Don't more segment registers cause more overhead for context switches? It's just one more register that has to be saved. I don't think it's going to matter much. -- "Some folks are into open source, but me, I'm into open bar." -- Spencer F. Katt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 19:21:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 77B9337B4CF; Tue, 21 Nov 2000 19:21:40 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA28087; Tue, 21 Nov 2000 22:21:19 -0500 (EST) Date: Tue, 21 Nov 2000 22:21:19 -0500 (EST) From: Daniel Eischen To: Jake Burkholder Cc: John Baldwin , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: <20001122015756.AF470BA7A@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, Jake Burkholder wrote: > Doug uses $8 (t7) on the alpha for the per-cpu data pointer, and r13 > on ia64. Not that that means anything to me. > > alpha/inclue/globals.h: > > register struct globaldata *globalp __asm__("$8"); > > ia64/include/globals.h: > > register struct globaldata *globalp __asm__("r13"); > > Its not really relevant if they're the same in and out of the kernel > cause the memory isn't addressable in both places anyway. I don't necessarily even need them to point to anything. Just an index into a table is sufficient, though it might be more efficient to use it as a pointer on architectures where its large enough. -- "Some folks are into open source, but me, I'm into open bar." -- Spencer F. Katt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 19:23:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6212F37B4D7; Tue, 21 Nov 2000 19:23:33 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAM3NW925749; Tue, 21 Nov 2000 19:23:32 -0800 (PST) Date: Tue, 21 Nov 2000 19:23:32 -0800 From: Alfred Perlstein To: Daniel Eischen Cc: John Baldwin , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs Message-ID: <20001121192331.E18037@fw.wintelcom.net> References: <20001121175100.B18037@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Tue, Nov 21, 2000 at 10:15:28PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Daniel Eischen [001121 19:15] wrote: > > > > Don't more segment registers cause more overhead for context switches? > > It's just one more register that has to be saved. I don't > think it's going to matter much. No extra TLB faults/invalidations? Aren't segment registers somewhat expensive to load? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 19:34:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 62B0537B4CF; Tue, 21 Nov 2000 19:34:12 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id WAA29543; Tue, 21 Nov 2000 22:33:50 -0500 (EST) Date: Tue, 21 Nov 2000 22:33:50 -0500 (EST) From: Daniel Eischen To: Alfred Perlstein Cc: John Baldwin , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: <20001121192331.E18037@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, Alfred Perlstein wrote: > * Daniel Eischen [001121 19:15] wrote: > > > > > > Don't more segment registers cause more overhead for context switches? > > > > It's just one more register that has to be saved. I don't > > think it's going to matter much. > > No extra TLB faults/invalidations? Aren't segment registers > somewhat expensive to load? Not according to swtch.s, it's just a movl instruction. I don't need to use the segment register to address anything. I just need to load it with a value (an index into a global array of per-KSE structures). If I'm being dense, feel free to smack me (just don't take too much enjoyment in it). -- "Some folks are into open source, but me, I'm into open bar." -- Spencer F. Katt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 20: 7:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id EC2FE37B479 for ; Tue, 21 Nov 2000 20:07:27 -0800 (PST) Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id UAA21967; Tue, 21 Nov 2000 20:05:41 -0800 Date: Tue, 21 Nov 2000 20:05:41 -0800 From: Arun Sharma To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs Message-ID: <20001121200541.A21911@sharmas.dhs.org> References: <20001121192331.E18037@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from eischen@vigrid.com on Tue, Nov 21, 2000 at 10:33:50PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 21, 2000 at 10:33:50PM -0500, Daniel Eischen wrote: > On Tue, 21 Nov 2000, Alfred Perlstein wrote: > > * Daniel Eischen [001121 19:15] wrote: > > > > > > > > Don't more segment registers cause more overhead for context switches? > > > > > > It's just one more register that has to be saved. I don't > > > think it's going to matter much. > > > > No extra TLB faults/invalidations? Aren't segment registers > > somewhat expensive to load? > > Not according to swtch.s, it's just a movl instruction. I don't > need to use the segment register to address anything. I just > need to load it with a value (an index into a global array > of per-KSE structures). Loading a segment register on x86 results in privilege level checking. It may even generate a general protection fault. Section 4.6 of vol 3 (system programming guide) from Intel has more details. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 20:58:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from io.yi.org (h24-69-199-88.gv.shawcable.net [24.69.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 4C55437B479; Tue, 21 Nov 2000 20:58:42 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 0C16EBA7A; Tue, 21 Nov 2000 20:58:43 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Eischen Cc: Alfred Perlstein , John Baldwin , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: Message from Daniel Eischen of "Tue, 21 Nov 2000 22:33:50 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Nov 2000 20:58:43 -0800 From: Jake Burkholder Message-Id: <20001122045843.0C16EBA7A@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 21 Nov 2000, Alfred Perlstein wrote: > > * Daniel Eischen [001121 19:15] wrote: > > > > > > > > Don't more segment registers cause more overhead for context switches? > > > > > > It's just one more register that has to be saved. I don't > > > think it's going to matter much. > > > > No extra TLB faults/invalidations? Aren't segment registers > > somewhat expensive to load? > > Not according to swtch.s, it's just a movl instruction. I don't > need to use the segment register to address anything. I just > need to load it with a value (an index into a global array > of per-KSE structures). > > If I'm being dense, feel free to smack me (just don't take too > much enjoyment in it). Actually this is probably a reason to use %fs, its already saved and restored on entry and exit to the kernel. These are the user-mode register values, so they get saved on the kernel stack in the system call and trap IDTVEC stubs, cpu_switch deals with the kernel mode register values. And yeah, loading the segment registers is expensive comparatively. > > -- > "Some folks are into open source, but me, I'm into open bar." > -- Spencer F. Katt > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 21:26:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9550937B4D7 for ; Tue, 21 Nov 2000 21:26:53 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id AAA13764; Wed, 22 Nov 2000 00:26:30 -0500 (EST) Date: Wed, 22 Nov 2000 00:26:29 -0500 (EST) From: Daniel Eischen To: Arun Sharma Cc: arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: <20001121200541.A21911@sharmas.dhs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, Arun Sharma wrote: > On Tue, Nov 21, 2000 at 10:33:50PM -0500, Daniel Eischen wrote: > > On Tue, 21 Nov 2000, Alfred Perlstein wrote: > > > * Daniel Eischen [001121 19:15] wrote: > > > > > > > > > > Don't more segment registers cause more overhead for context switches? > > > > > > > > It's just one more register that has to be saved. I don't > > > > think it's going to matter much. > > > > > > No extra TLB faults/invalidations? Aren't segment registers > > > somewhat expensive to load? > > > > Not according to swtch.s, it's just a movl instruction. I don't > > need to use the segment register to address anything. I just > > need to load it with a value (an index into a global array > > of per-KSE structures). > > Loading a segment register on x86 results in privilege level checking. > It may even generate a general protection fault. > > Section 4.6 of vol 3 (system programming guide) from Intel > has more details. Any other ideas? -- "Some folks are into open source, but me, I'm into open bar." -- Spencer F. Katt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 22:24:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C6A1237B479; Tue, 21 Nov 2000 22:24:30 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAM6OTQ33939; Tue, 21 Nov 2000 23:24:29 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA40393; Tue, 21 Nov 2000 23:24:29 -0700 (MST) Message-Id: <200011220624.XAA40393@harmony.village.org> To: opentrax@email.com Subject: Re: New security policy for FreeBSD 3.x Cc: security-officer@FreeBSD.ORG, arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 21 Nov 2000 10:43:05 PST." <200011211843.KAA00298@spammie.svbug.com> References: <200011211843.KAA00298@spammie.svbug.com> Date: Tue, 21 Nov 2000 23:24:29 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011211843.KAA00298@spammie.svbug.com> opentrax@email.com writes: : Please note I've cc'd to arch. Could you make your : comments there? : : On 19 Nov, FreeBSD Security Advisories wrote: : > -----BEGIN PGP SIGNED MESSAGE----- : > : > The FreeBSD Security Officer would like to announce a change in policy : > regarding security support for the FreeBSD 3.x branch. : > : > Due to the frequent difficulties encountered in fixing the old code : > contained in FreeBSD 3.x, we will no longer be requiring security : > problems to be fixed in that branch prior to the release of an : > advisory that also pertains to FreeBSD 4.x. In recent months this : > requirement has led to delays in the release of advisories, which : > negatively impacts users of the current FreeBSD release branch : > (FreeBSD 4.x). : > : Could you clarify exactly what you are saying? It's not clear. : Perhaps a chart might help. [[ included original text to give context ]] Generally speaking, fixes go into -current first, then are MFC to 4.x-stable and then MFC to 3.x-stable. Sometimes the MFC is easy (when the code is substantially identical) and sometimes it isn't. In the cases it isn't, we won't hold up the advisory for a 3.x fix. We will inform select interested and sufficiently clueful parties of pending advisories for which no 3.x solution is available. If they can get us a fix for 3.x before we release our advisory (usually a few days to a week depending on its severity and other factors), we will include it in the advisory. If not, then the advisory goes out anyway without a 3.x fix, with the usual room for negotiation for reasonable extensions. In other words, fixes for 3.x will no longer gate security advisories, but will be included if available. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 23:36:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id AC36737B4CF for ; Tue, 21 Nov 2000 23:36:51 -0800 (PST) Received: from z3 ([192.168.1.15]) by sharmas.dhs.org (8.9.3/8.9.3) with SMTP id XAA22643; Tue, 21 Nov 2000 23:35:05 -0800 Message-ID: <003d01c0538d$9646f260$7840a8c0@escalate.com> From: "Arun Sharma" To: "Daniel Eischen" Cc: References: Subject: Re: Thread-specific data and KSEs Date: Mon, 20 Nov 2000 23:35:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----- Original Message ----- From: Daniel Eischen To: Arun Sharma Cc: Sent: Tuesday, November 21, 2000 9:26 PM Subject: Re: Thread-specific data and KSEs > > > > Loading a segment register on x86 results in privilege level checking. > > It may even generate a general protection fault. > > > > Section 4.6 of vol 3 (system programming guide) from Intel > > has more details. > > Any other ideas? Linux threads implementation uses %gs to store a pointer to the thread structure. A segment register can only be loaded with a selector that points to a valid entry in a LDT or a GDT on x86. They do the trick by using a system call to make an entry in the LDT. In other words, the number of threads is limited by the number of entries in the LDT :) They still pay the cost of a privilege check each time they load %gs. I don't really know if it is too much of a price to pay in a thread library implementation. Other ideas: Use fixed registers to store the pointer to pthread_whatever_struct on archictures that allow it and on x86 and friends, just let the compiler pick an unused register (you might want to use the "register" keyword). The implementation can be hidden away in an (architecture specific) macro. [ reference to linuxthreads ]: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/linuxthreads/sysdeps/i386/useldt.h?rev=1.7&content-type=text/x-cvsweb-markup&cvsro ot=glibc -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 23:46:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id DCC2337B657; Tue, 21 Nov 2000 23:46:29 -0800 (PST) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 13yUbr-000O0F-0X; Wed, 22 Nov 2000 07:46:28 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id HAA90239; Wed, 22 Nov 2000 07:49:19 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 22 Nov 2000 07:47:03 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Daniel Eischen , Jonathan Lemon , arch@freebsd.org Subject: Re: Thread-specific data and KSEs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, John Baldwin wrote: > Well, %gs would cover x86 and k64. I think ia64 has several application > registers that are available for OS use and we could steal one of those. I'm > not sure about the alpha though. On ia64, we already use r13 (defined by the ABI as the 'thread pointer') to point at per-cpu locals. In user-mode, r13 should also be reserved. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 21 23:50:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id DBE0C37B4C5; Tue, 21 Nov 2000 23:50:56 -0800 (PST) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 13yUgB-000FUJ-0K; Wed, 22 Nov 2000 07:50:55 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id HAA90277; Wed, 22 Nov 2000 07:53:51 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 22 Nov 2000 07:51:35 +0000 (GMT) From: Doug Rabson To: Jake Burkholder Cc: John Baldwin , Daniel Eischen , Jonathan Lemon , arch@freebsd.org Subject: Re: Thread-specific data and KSEs In-Reply-To: <20001122015756.AF470BA7A@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 21 Nov 2000, Jake Burkholder wrote: > > Well, %gs would cover x86 and k64. I think ia64 has several application > > registers that are available for OS use and we could steal one of those. I'm > > not sure about the alpha though. > > > > Doug uses $8 (t7) on the alpha for the per-cpu data pointer, and r13 > on ia64. Not that that means anything to me. > > alpha/inclue/globals.h: > > register struct globaldata *globalp __asm__("$8"); > > ia64/include/globals.h: > > register struct globaldata *globalp __asm__("r13"); > > Its not really relevant if they're the same in and out of the kernel > cause the memory isn't addressable in both places anyway. For alpha in user mode, we should use the 'process unique value' which is accessable with 'call_pal PAL_rdunique' and 'call_pal PAL_wrunique'. In kernel mode, just stick something in the pcpu structure probably. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 4:33: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 680AB37B479 for ; Wed, 22 Nov 2000 04:33:00 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA05111; Wed, 22 Nov 2000 07:32:33 -0500 (EST) Date: Wed, 22 Nov 2000 07:32:33 -0500 (EST) From: Daniel Eischen To: Arun Sharma Cc: arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: <003d01c0538d$9646f260$7840a8c0@escalate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 20 Nov 2000, Arun Sharma wrote: > Linux threads implementation uses %gs to store a pointer to > the thread structure. A segment register can only be loaded > with a selector that points to a valid entry in a LDT or a GDT > on x86. Hmm, OK. So if I initially load the LDT with entries (they don't have to point to anything unless I want to really use gs to point to something), then I can use gs. > They do the trick by using a system call to make an entry in > the LDT. In other words, the number of threads is limited by > the number of entries in the LDT :) For us, we'd be limited to the number of KSEs. I think a limit of 8188 KSEs (2^13 - 4, right?) should be more than sufficient. The number of threads could essentially be unlimited. > They still pay the cost of a privilege check each time they > load %gs. I don't really know if it is too much of a price to > pay in a thread library implementation. I don't see any other ways for i386. > Other ideas: > > Use fixed registers to store the pointer to pthread_whatever_struct > on archictures that allow it and on x86 and friends, just let the > compiler pick an unused register (you might want to use the "register" > keyword). The implementation can be hidden away in an > (architecture specific) macro. I'm not sure I follow you. The register and it's value must remain static across subprogram calls, both in the threads library and in application code. Other than the segment registers, there's not many registers available for i386 where we could afford to set one aside. > [ reference to linuxthreads ]: Thanks -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 4:35:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 324C637B479; Wed, 22 Nov 2000 04:35:08 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA05253; Wed, 22 Nov 2000 07:34:08 -0500 (EST) Date: Wed, 22 Nov 2000 07:34:08 -0500 (EST) From: Daniel Eischen To: Doug Rabson Cc: Jake Burkholder , John Baldwin , Jonathan Lemon , arch@freebsd.org Subject: Re: Thread-specific data and KSEs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 22 Nov 2000, Doug Rabson wrote: > For alpha in user mode, we should use the 'process unique value' which is > accessable with 'call_pal PAL_rdunique' and 'call_pal PAL_wrunique'. In > kernel mode, just stick something in the pcpu structure probably. Thanks, I forgot about these. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 7: 7:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from spammie.svbug.com (mg134-015.ricochet.net [204.179.134.15]) by hub.freebsd.org (Postfix) with ESMTP id DF3DF37B4D7; Wed, 22 Nov 2000 07:07:29 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id HAA00642; Wed, 22 Nov 2000 07:06:34 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200011221506.HAA00642@spammie.svbug.com> Date: Wed, 22 Nov 2000 07:06:32 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: New security policy for FreeBSD 3.x To: imp@village.org Cc: security-officer@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: <200011220624.XAA40393@harmony.village.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21 Nov, Warner Losh wrote: > In message <200011211843.KAA00298@spammie.svbug.com> opentrax@email.com writes: > : Please note I've cc'd to arch. Could you make your > : comments there? > : > : On 19 Nov, FreeBSD Security Advisories wrote: > : > -----BEGIN PGP SIGNED MESSAGE----- > : > > : > The FreeBSD Security Officer would like to announce a change in policy > : > regarding security support for the FreeBSD 3.x branch. > : > > : > Due to the frequent difficulties encountered in fixing the old code > : > contained in FreeBSD 3.x, we will no longer be requiring security > : > problems to be fixed in that branch prior to the release of an > : > advisory that also pertains to FreeBSD 4.x. In recent months this > : > requirement has led to delays in the release of advisories, which > : > negatively impacts users of the current FreeBSD release branch > : > (FreeBSD 4.x). > : > > : Could you clarify exactly what you are saying? It's not clear. > : Perhaps a chart might help. > > [[ included original text to give context ]] > > Generally speaking, fixes go into -current first, then are MFC to > 4.x-stable and then MFC to 3.x-stable. Sometimes the MFC is easy > (when the code is substantially identical) and sometimes it isn't. In > the cases it isn't, we won't hold up the advisory for a 3.x fix. We > will inform select interested and sufficiently clueful parties of > pending advisories for which no 3.x solution is available. If they > can get us a fix for 3.x before we release our advisory (usually a few > days to a week depending on its severity and other factors), we will > include it in the advisory. If not, then the advisory goes out anyway > without a 3.x fix, with the usual room for negotiation for reasonable > extensions. > > In other words, fixes for 3.x will no longer gate security > advisories, but will be included if available. > Thank you for taking the time to explain this Warner. The original advisory was not as clear. However, I still fell a bit confused. As such, I would like to write a document that would explain this situation. This document would include a chart to help those that might need assitance (like me). I beleive that such a document would prove useful and would help the security-officer by providing a definitive document that could be pointed to. This document could also be included in future advisories, where needed. Let me say lastly that my first impression of this 'advisory' was not what you said, thereby leading to my confusion. Since I believe it clear, I would then suggest the aforementioned document which I am willing to collect/author/edit. best regards, Jessem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 7:15:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id AA3E037B4C5; Wed, 22 Nov 2000 07:15:25 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13ybc7-00049r-00; Wed, 22 Nov 2000 17:15:11 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id RAA24982; Wed, 22 Nov 2000 17:15:21 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 24825; Wed Nov 22 17:14:53 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13ybbp-000A4i-00; Wed, 22 Nov 2000 17:14:53 +0200 From: Sheldon Hearn Reply-To: chat@freebsd.org To: opentrax@email.com Cc: imp@village.org, security-officer@freebsd.org, arch@freebsd.org Subject: Re: New security policy for FreeBSD 3.x In-reply-to: Your message of "Wed, 22 Nov 2000 07:06:32 PST." <200011221506.HAA00642@spammie.svbug.com> Date: Wed, 22 Nov 2000 17:14:53 +0200 Message-ID: <38731.974906093@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Cross-post to -arch is ridiculous, follow-up to -chat] On Wed, 22 Nov 2000 07:06:32 PST, opentrax@email.com wrote: > Thank you for taking the time to explain this Warner. > The original advisory was not as clear. However, I still fell > a bit confused. Probably because you haven't read http://www.freebsd.org/handbook/cutting-edge.html . Once you've read it, you're welcome to send patches for improving it. In fact, the documentation project folks are so fanatical that they'll usually accept contributions that are not in patch format and work your stuff into the files manually. But keep in mind that no matter how good you help us make the documentation, there'll always be some idiot out there who refuses to read it. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 7:41:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from spammie.svbug.com (mg134-015.ricochet.net [204.179.134.15]) by hub.freebsd.org (Postfix) with ESMTP id 1A78137B4C5; Wed, 22 Nov 2000 07:41:22 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id HAA00692; Wed, 22 Nov 2000 07:40:39 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200011221540.HAA00692@spammie.svbug.com> Date: Wed, 22 Nov 2000 07:40:38 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: New security policy for FreeBSD 3.x To: chat@FreeBSD.ORG Cc: imp@village.org, security-officer@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: <38731.974906093@axl.fw.uunet.co.za> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22 Nov, Sheldon Hearn wrote: > > [Cross-post to -arch is ridiculous, follow-up to -chat] > > On Wed, 22 Nov 2000 07:06:32 PST, opentrax@email.com wrote: > >> Thank you for taking the time to explain this Warner. >> The original advisory was not as clear. However, I still fell >> a bit confused. > > Probably because you haven't read > http://www.freebsd.org/handbook/cutting-edge.html . > > Once you've read it, you're welcome to send patches for improving it. > In fact, the documentation project folks are so fanatical that they'll > usually accept contributions that are not in patch format and work your > stuff into the files manually. > > But keep in mind that no matter how good you help us make the > documentation, there'll always be some idiot out there who refuses to > read it. > I appoligize for not being clear on this, but 'cutting-edge' has never been my intent. Nor, do I see this as an item for inclusion in the handbook(but I should take that up with 'doc'). :-) Security by most measure sits in it's own space. That is, if a security breach exists, then it must be dealt with immediately (if not sooner). However, on that same line, the change in policy, as this current one is, tends toward NO change. That is, the policy is "we're interest in the change, but not at the cost of delaying a change that must be expedited". So in this case, we error on the side of caution. Discontinuing the rant, the website needs better organization, but again I know I must take this up with 'docs'. Thanks again, Jessem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 10:28: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 9628837B4C5 for ; Wed, 22 Nov 2000 10:28:03 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAMIRh041632; Wed, 22 Nov 2000 10:27:43 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eAMINr255285; Wed, 22 Nov 2000 10:23:53 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001121175100.B18037@fw.wintelcom.net> Date: Wed, 22 Nov 2000 10:23:53 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Alfred Perlstein Subject: Re: Thread-specific data and KSEs Cc: arch@FreeBSD.ORG, Jonathan Lemon , Daniel Eischen Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Alfred Perlstein wrote: > * John Baldwin [001121 17:19] wrote: >> >> On 22-Nov-00 Daniel Eischen wrote: >> >> %gs ? as I mentioned in my other message, this one might be useful for >> >> addressing a structure of thread-local variables much like %fs is used >> >> for >> >> per-CPU data. It also has value in that supposedly x86-64 (aka k64) has >> >> both >> >> %fs and %gs, but no other seg regs. >> > >> > All I need is one. >> >> Well, %gs would cover x86 and k64. I think ia64 has several application >> registers that are available for OS use and we could steal one of those. >> I'm >> not sure about the alpha though. > > Don't more segment registers cause more overhead for context switches? Hardly. The biggest pain involved in a context switch is the TLB, not 2 (4?) extra mov instructions. :) > Just wondering. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 10:31:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 4AE2A37B4C5 for ; Wed, 22 Nov 2000 10:31:44 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAMIVT041749; Wed, 22 Nov 2000 10:31:29 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eAMIRcg55300; Wed, 22 Nov 2000 10:27:38 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001121192331.E18037@fw.wintelcom.net> Date: Wed, 22 Nov 2000 10:27:38 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Alfred Perlstein Subject: Re: Thread-specific data and KSEs Cc: arch@FreeBSD.ORG, Jonathan Lemon , Daniel Eischen Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Alfred Perlstein wrote: > * Daniel Eischen [001121 19:15] wrote: >> > >> > Don't more segment registers cause more overhead for context switches? >> >> It's just one more register that has to be saved. I don't >> think it's going to matter much. > > No extra TLB faults/invalidations? Aren't segment registers > somewhat expensive to load? Not really. The TLB stuff happens when you change %cr3. Also, if you look in cpu_switch, we already save and restore %gs. :) (Which means it may already be used. :( ) Some extra overhead may come from changing the ldt, although if you stick USER_LDT in your kernel you already do that anyways. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 11:17:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1895837B479 for ; Wed, 22 Nov 2000 11:17:31 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA47152; Wed, 22 Nov 2000 14:17:21 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Nov 2000 14:17:21 -0500 (EST) From: Garrett Wollman Message-Id: <200011221917.OAA47152@khavrinen.lcs.mit.edu> To: bright@wintelcom.net Subject: Re: Thread-specific data and KSEs X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Sorry I'm coming into this late -- I only read this list rarely, and through news at that.] In article you write: >No extra TLB faults/invalidations? Aren't segment registers >somewhat expensive to load? Segment register loads are the most expensive thing you can do, in a single instruction, on an Intel-architecture processor, that doesn't result in taking a trap.[1] Having said that, we already have some of the overhead: FS and GS are used in the kernel to limit the kernel's access when following user pointers. See the internals of copyin(), copyout(), [fs]uword(), etc. Upon entry to the kernel, we load appropriate selectors for this purpose, and restore the user's selectors on exit. However, some of the overhead is avoided for normal FreeBSD ABI applications, since we end up ``saving'' and ``restoring'' the same value all the time. (User programs don't muck with the segment registers.) If you can somehow arrange to put your pointer on the stack -- or practically anywhere else -- it would probably be preferable to using a segment register, as it would avoid the overhead of both segment register loads and LDTR loads. (IIRC, when you load the LDTR it automatically flushes the segment attribute cache, which ensures that future segment register loads are as expensive as possible.) -GAWollman [1] Well, perhaps this is no longer true. It was true at least up to the first-generation Pentium. WinNT 3.51 spent something like a third of its context-switch time on seg-reg loads. -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 12:34:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 3B17837B4C5 for ; Wed, 22 Nov 2000 12:34:13 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAMKY4046218; Wed, 22 Nov 2000 12:34:04 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 22 Nov 2000 12:34:15 -0800 (PST) From: John Baldwin To: Daniel Eischen Subject: Re: Thread-specific data and KSEs Cc: arch@FreeBSD.org, Arun Sharma Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Daniel Eischen wrote: > On Mon, 20 Nov 2000, Arun Sharma wrote: >> Linux threads implementation uses %gs to store a pointer to >> the thread structure. A segment register can only be loaded >> with a selector that points to a valid entry in a LDT or a GDT >> on x86. > > Hmm, OK. So if I initially load the LDT with entries (they > don't have to point to anything unless I want to really > use gs to point to something), then I can use gs. Entries in the LDT have to point to something, that's all they can do. You could in theory make them all be zero length or some such, but you might need more thread-local storage than a single 16-bit integer that would require 4k of backing store to avoid causing seg faults. If each KSE has its own LDT, on the other hand, then you can use a fixed entry in the LDT to point to the thread-local data (so that %gs doesn't have to change) much like we do for per-CPU data with %fs in the kernel. You can then use stuff similar to machine/globals.h to access each variable in the threaddata struct. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 12:40:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id BE70D37B4CF; Wed, 22 Nov 2000 12:40:42 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eAMKefa01052; Wed, 22 Nov 2000 21:40:41 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org, arch@freebsd.org Subject: RFC: /dev/console -> /var/log/messages idea/patch From: Poul-Henning Kamp Date: Wed, 22 Nov 2000 21:40:41 +0100 Message-ID: <1050.974925641@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The attached patch is a "proof-of-concept" on which I would like to get some comments: It bugs me big time that the output from /etc/rc and all other output to /dev/console is volatile and lost once it scrolls of your console. It particular bugs me for systems which are configured with a modem on a serial port as console, if something choked badly in /etc/rc I will never know. (Don't tell me to use a SilentWriter or DecWriter as console, OK ? Been There, Done That, Got The Piles Of Paper To Prove It. :-) Ideally our console would be much more functional, but that is a project which would fall sideways off my todo list if I tried to balance it there. (If anybody is looking for a medium complex kernel task, a new console system is a place to look. Enquire within). So I though about it from a "how little can we get away with" and realized that by simply grabbing a copy of everything written to /dev/console and feeding it to syslogd would gain us a lot of mileage. Now, there are several issues to understand here, so please read on before you apply paint to this bikeshed: By "/dev/console" output I mean just and only that. Characters which arrive by write(2)/writev(2) on a fd opened to "/dev/console". Kernel printfs are not /dev/console output in this context. Characters written directly to your console device ("/dev/ttyd0", "/dev/ttyv0" or "/dev/cuaa0") are *not* /dev/console output either. Input from /dev/console are not part of this. You will not be able to see the answers people give fsck. The output do of course still also arrive on your console device. Obviously, if syslogd were to write these messages back to /dev/console bad things would happen. Syslogd may need to gain a tabu there. The formatting cannot be preserved. If somebody were to: echo -n "You're screwed now ---> " > /dev/console we would never see the message in syslogd if the code waited for the final '\n' to arrive. (I guess a timeout based solution could be feasible, what do people think ?) In this patch I have deliberatly output a '"' in front of all messages, this is merely for debugging right now. The patch probably has all sorts of issues, style, locking, you name it. It is only intended as a proof-of-concept patch. Sample output from /var/log/messages attached below. Comments, volounteers, ideas most welcome... Poul-Henning Nov 22 21:16:38 syv /boot/kernel/kernel: "swapon: adding /dev/ad1s1b as swap device Nov 22 21:16:38 syv /boot/kernel/kernel: "swapon: adding /dev/ad0s1b as swap device Nov 22 21:16:38 syv /boot/kernel/kernel: "Automatic boot in progress... Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ad0s1a: Nov 22 21:16:38 syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING CHECKS Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ad0s1a: Nov 22 21:16:38 syv /boot/kernel/kernel: "clean, 134807 free Nov 22 21:16:38 syv /boot/kernel/kernel: "(823 frags, 16748 blocks, 0.4% fragmentation) Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ad1s1e: Nov 22 21:16:38 syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING CHECKS Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ad1s1e: Nov 22 21:16:38 syv /boot/kernel/kernel: "clean, 184706 free Nov 22 21:16:38 syv /boot/kernel/kernel: "(138 frags, 23071 blocks, 0.1% fragmentation) Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ad1s1f: Nov 22 21:16:38 syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING CHECKS Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ad1s1f: Nov 22 21:16:38 syv /boot/kernel/kernel: "clean, 1775231 free Nov 22 21:16:38 syv /boot/kernel/kernel: "(13343 frags, 220236 blocks, 0.7% fragmentation) Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ad0s1e: Nov 22 21:16:38 syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING CHECKS Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ad0s1e: Nov 22 21:16:38 syv /boot/kernel/kernel: "clean, 2032838 free Nov 22 21:16:38 syv /boot/kernel/kernel: "(14 frags, 254103 blocks, 0.0% fragmentation) Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ccd0c: Nov 22 21:16:38 syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING CHECKS Nov 22 21:16:38 syv /boot/kernel/kernel: "/dev/ccd0c: Nov 22 21:16:38 syv /boot/kernel/kernel: "clean, 3464429 free Nov 22 21:16:38 syv /boot/kernel/kernel: "(3245 frags, 865296 blocks, 0.1% fragmentation) Nov 22 21:16:38 syv /boot/kernel/kernel: "Can't use /entropy as an entropy file, trying other sources Nov 22 21:16:38 syv /boot/kernel/kernel: "cat: Nov 22 21:16:38 syv /boot/kernel/kernel: "malloc.conf Nov 22 21:16:38 syv /boot/kernel/kernel: ": Nov 22 21:16:38 syv /boot/kernel/kernel: "No such file or directory Nov 22 21:16:38 syv /boot/kernel/kernel: "Doing initial network setup: Nov 22 21:16:38 syv /boot/kernel/kernel: " hostname Nov 22 21:16:38 syv /boot/kernel/kernel: ". Nov 22 21:16:38 syv /boot/kernel/kernel: "fxp0: flags=8843 mtu 1500 Nov 22 21:16:38 syv /boot/kernel/kernel: " inet 212.242.40.133 netmask 0xfffffff0 broadcast 212.242.40.143 Nov 22 21:16:38 syv /boot/kernel/kernel: " ether 00:90:27:2c:60:72 Nov 22 21:16:38 syv /boot/kernel/kernel: " media: autoselect (100baseTX ) status: active Nov 22 21:16:38 syv /boot/kernel/kernel: " supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP Nov 22 21:16:38 syv /boot/kernel/kernel: "lo0: flags=8049 mtu 16384 Nov 22 21:16:38 syv /boot/kernel/kernel: " inet 127.0.0.1 netmask 0xff000000 Nov 22 21:16:38 syv /boot/kernel/kernel: "add net default: gateway 212.242.40.129 Nov 22 21:16:38 syv /boot/kernel/kernel: "Additional routing options: Nov 22 21:16:38 syv /boot/kernel/kernel: " tcp extensions=NO Nov 22 21:16:38 syv /boot/kernel/kernel: " TCP keepalive=YES Nov 22 21:16:38 syv /boot/kernel/kernel: ". Nov 22 21:16:38 syv /boot/kernel/kernel: "routing daemons: Nov 22 21:16:38 syv /boot/kernel/kernel: ". Nov 22 21:16:38 syv /boot/kernel/kernel: "additional daemons: Nov 22 21:16:38 syv /boot/kernel/kernel: " syslogd Nov 22 21:16:38 syv /boot/kernel/kernel: ". Nov 22 21:16:38 syv /boot/kernel/kernel: "rm: Nov 22 21:16:38 syv /boot/kernel/kernel: "/var/run/dev.db Nov 22 21:16:38 syv /boot/kernel/kernel: ": Nov 22 21:16:38 syv /boot/kernel/kernel: "No such file or directory Nov 22 21:16:38 syv /boot/kernel/kernel: "Doing additional network setup: Nov 22 21:16:38 syv /boot/kernel/kernel: " portmap Nov 22 21:16:39 syv /boot/kernel/kernel: ". Nov 22 21:16:39 syv /boot/kernel/kernel: "Starting final network daemons: Nov 22 21:16:39 syv /boot/kernel/kernel: ". Nov 22 21:16:39 syv /boot/kernel/kernel: "setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib Nov 22 21:16:39 syv /boot/kernel/kernel: "setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Nov 22 21:16:39 syv /boot/kernel/kernel: "starting standard daemons: Nov 22 21:16:39 syv /boot/kernel/kernel: " inetd Nov 22 21:16:39 syv /boot/kernel/kernel: " cron Nov 22 21:16:39 syv /boot/kernel/kernel: " sendmail Nov 22 21:16:39 syv /boot/kernel/kernel: " sshd Nov 22 21:16:39 syv /boot/kernel/kernel: ". Nov 22 21:16:39 syv /boot/kernel/kernel: "Recovering vi editor sessions Nov 22 21:16:40 syv /boot/kernel/kernel: "Initial rc.i386 initialization: Nov 22 21:16:40 syv /boot/kernel/kernel: ". Nov 22 21:16:40 syv /boot/kernel/kernel: "rc.i386 configuring syscons: Nov 22 21:16:40 syv /boot/kernel/kernel: " blank_time Nov 22 21:16:40 syv /boot/kernel/kernel: ". Nov 22 21:16:40 syv /boot/kernel/kernel: "additional ABI support: Nov 22 21:16:40 syv /boot/kernel/kernel: ". Nov 22 21:16:40 syv /boot/kernel/kernel: "Local package initialization: Nov 22 21:16:40 syv /boot/kernel/kernel: ". Nov 22 21:16:40 syv /boot/kernel/kernel: "Additional TCP options: Nov 22 21:16:40 syv /boot/kernel/kernel: ". Index: sys/syslog.h =================================================================== RCS file: /home/ncvs/src/sys/sys/syslog.h,v retrieving revision 1.19 diff -u -r1.19 syslog.h --- sys/syslog.h 1999/12/29 04:24:48 1.19 +++ sys/syslog.h 2000/11/22 20:02:26 @@ -107,6 +107,7 @@ #define LOG_FTP (11<<3) /* ftp daemon */ #define LOG_NTP (12<<3) /* NTP subsystem */ #define LOG_SECURITY (13<<3) /* security subsystems (firewalling, etc.) */ +#define LOG_CONSOLE (14<<3) /* /dev/console output */ /* other codes through 15 reserved for system use */ #define LOG_LOCAL0 (16<<3) /* reserved for local use */ @@ -127,6 +128,7 @@ CODE facilitynames[] = { { "auth", LOG_AUTH, }, { "authpriv", LOG_AUTHPRIV, }, + { "console", LOG_CONSOLE, }, { "cron", LOG_CRON, }, { "daemon", LOG_DAEMON, }, { "ftp", LOG_FTP, }, Index: kern/subr_prf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_prf.c,v retrieving revision 1.64 diff -u -r1.64 subr_prf.c --- kern/subr_prf.c 2000/10/02 07:13:10 1.64 +++ kern/subr_prf.c 2000/11/22 20:14:50 @@ -49,6 +49,7 @@ #include #include #include +#include /* * Note that stdarg.h and the ANSI style va_start macro is used for both @@ -223,6 +224,52 @@ logwakeup(); return retval; } + +#define CONSCHUNK 4096 +static char consbuffer[CONSCHUNK]; + +void +log_console(struct uio *uio) +{ + int s, c, i, error, iovlen, nlf = 0; + struct uio muio; + struct iovec *miov = NULL; + + muio = *uio; + iovlen = uio->uio_iovcnt * sizeof (struct iovec); + MALLOC(miov, struct iovec *, iovlen, M_TEMP, M_WAITOK); + bcopy((caddr_t)muio.uio_iov, (caddr_t)miov, iovlen); + muio.uio_iov = miov; + uio = &muio; + + s = splhigh(); + error = 0; + while (error == 0 && uio->uio_resid > 0) { + c = imin(uio->uio_resid, CONSCHUNK); + error = uiomove(consbuffer, c, uio); + if (!error) { + for (i = 0; i < c; i++) { + if (!nlf) { + logpri(LOG_INFO | LOG_CONSOLE); + msglogchar('"', 0); + nlf = 1; + } + msglogchar(consbuffer[i], 0); + if (consbuffer[i] == '\n') { + nlf = 0; + logwakeup(); + } + } + } + } + if (nlf) + msglogchar('\n', 0); + logwakeup(); + splx(s); + FREE(miov, M_TEMP); + return; +} + static void logpri(level) Index: kern/tty_cons.c =================================================================== RCS file: /home/ncvs/src/sys/kern/tty_cons.c,v retrieving revision 1.84 diff -u -r1.84 tty_cons.c --- kern/tty_cons.c 2000/10/29 16:06:34 1.84 +++ kern/tty_cons.c 2000/11/22 20:20:20 @@ -352,6 +352,7 @@ dev = constty->t_dev; else dev = cn_tab->cn_dev; + log_console(uio); return ((*devsw(dev)->d_write)(dev, uio, flag)); } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 12:58:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from kyra.unloved.org (kyra.unloved.org [62.58.62.162]) by hub.freebsd.org (Postfix) with ESMTP id EEC6E37B4CF; Wed, 22 Nov 2000 12:58:11 -0800 (PST) Received: from ashp by kyra.unloved.org with local (Exim 3.15 #1) id 13ygyi-000Jbd-00; Wed, 22 Nov 2000 21:58:52 +0100 Date: Wed, 22 Nov 2000 21:58:52 +0100 From: Ashley Penney To: Poul-Henning Kamp Cc: current@freebsd.org, arch@freebsd.org Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch Message-ID: <20001122215852.A75332@kyra.unloved.org> References: <1050.974925641@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1050.974925641@critter>; from phk@freebsd.org on Wed, Nov 22, 2000 at 09:40:41PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 22, 2000 at 09:40:41PM +0100, Poul-Henning Kamp said: > > The attached patch is a "proof-of-concept" on which I would like > to get some comments: I'm only a moronic user, but this would make my life easier. My machine switches into 132x43 on startup, and I always lose the output. So this is just me saying "Yay for phk." -- Pine vs Mutt : It's like the difference between playing with yourself and getting head from a hot girl. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 13: 0:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BCB0A37B479; Wed, 22 Nov 2000 13:00:31 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA20648; Wed, 22 Nov 2000 16:00:11 -0500 (EST) Date: Wed, 22 Nov 2000 16:00:11 -0500 (EST) From: Daniel Eischen To: John Baldwin Cc: arch@FreeBSD.org, Arun Sharma Subject: Re: Thread-specific data and KSEs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 22 Nov 2000, John Baldwin wrote: > On 22-Nov-00 Daniel Eischen wrote: > > On Mon, 20 Nov 2000, Arun Sharma wrote: > >> Linux threads implementation uses %gs to store a pointer to > >> the thread structure. A segment register can only be loaded > >> with a selector that points to a valid entry in a LDT or a GDT > >> on x86. > > > > Hmm, OK. So if I initially load the LDT with entries (they > > don't have to point to anything unless I want to really > > use gs to point to something), then I can use gs. > > Entries in the LDT have to point to something, that's all they can do. You > could in theory make them all be zero length or some such, but you might need > more thread-local storage than a single 16-bit integer that would require 4k of > backing store to avoid causing seg faults. If each KSE has its own LDT, on the > other hand, then you can use a fixed entry in the LDT to point to the > thread-local data (so that %gs doesn't have to change) much like we do for > per-CPU data with %fs in the kernel. You can then use stuff similar to > machine/globals.h to access each variable in the threaddata struct. I only really need KSE specific data, since each KSE _always_ knows what thread it's running. When a KSE wants to run another thread, it just changes the thread ID/pointer in the KSE specific data. So CURTHREAD (or _thread_run for those of us that have fiddled with libc_r) would just be CURKSE()->ksd_curthread. If I use the value of %gs (probably %gs>>3 - 17) as an index into a global table of pointers to per-KSE structures, then I need not worry about what is in the LDT, as long as it is valid. I wrote a simple test program to load the remaining LDTs with the same values as the LUDATA_SEL LDT, and this seemed to work nicely. I'll definitely check out your suggestion of using different entries in the LDT for each KSE. Initially, it might make it easier to use %gs as a simple index, so it is easier to validate the entry when debugging the implementation. Thanks, -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 13: 6: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id F10D437B4C5 for ; Wed, 22 Nov 2000 13:06:01 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAML5q047491; Wed, 22 Nov 2000 13:05:52 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 22 Nov 2000 13:06:04 -0800 (PST) From: John Baldwin To: Daniel Eischen Subject: Re: Thread-specific data and KSEs Cc: Arun Sharma , arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Daniel Eischen wrote: > On Wed, 22 Nov 2000, John Baldwin wrote: >> On 22-Nov-00 Daniel Eischen wrote: >> > On Mon, 20 Nov 2000, Arun Sharma wrote: >> >> Linux threads implementation uses %gs to store a pointer to >> >> the thread structure. A segment register can only be loaded >> >> with a selector that points to a valid entry in a LDT or a GDT >> >> on x86. >> > >> > Hmm, OK. So if I initially load the LDT with entries (they >> > don't have to point to anything unless I want to really >> > use gs to point to something), then I can use gs. >> >> Entries in the LDT have to point to something, that's all they can do. You >> could in theory make them all be zero length or some such, but you might >> need >> more thread-local storage than a single 16-bit integer that would require 4k >> of >> backing store to avoid causing seg faults. If each KSE has its own LDT, on >> the >> other hand, then you can use a fixed entry in the LDT to point to the >> thread-local data (so that %gs doesn't have to change) much like we do for >> per-CPU data with %fs in the kernel. You can then use stuff similar to >> machine/globals.h to access each variable in the threaddata struct. > > I only really need KSE specific data, since each KSE _always_ knows > what thread it's running. When a KSE wants to run another thread, it > just changes the thread ID/pointer in the KSE specific data. So CURTHREAD > (or _thread_run for those of us that have fiddled with libc_r) would > just be CURKSE()->ksd_curthread. > > If I use the value of %gs (probably %gs>>3 - 17) as an index into > a global table of pointers to per-KSE structures, then I need not > worry about what is in the LDT, as long as it is valid. I wrote > a simple test program to load the remaining LDTs with the same > values as the LUDATA_SEL LDT, and this seemed to work nicely. Let %gs do its job. :) Seriously, look at how %fs is used in machine/globals.h. Have %gs:0 -> KSE specific data structure, then you can use %gs with fixed offsets to access KSE specific data. > I'll definitely check out your suggestion of using different entries > in the LDT for each KSE. Initially, it might make it easier to use > %gs as a simple index, so it is easier to validate the entry when > debugging the implementation. Eh, I would use a small LDT (LDT's don't have to be large if you don't have a lot of selectors) for each KSE with one statically configured selector that %gs is always set to that will point to the KSE data. Thus, when you create a KSE, you just setup its LDT to have the KSE data entry point to the KSE data. > Thanks, > > -- > Dan Eischen -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 13:12:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 38AD237B4C5; Wed, 22 Nov 2000 13:12:27 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id eAMLCMU07305; Wed, 22 Nov 2000 15:12:22 -0600 (CST) (envelope-from dan) Date: Wed, 22 Nov 2000 15:12:22 -0600 From: Dan Nelson To: Poul-Henning Kamp Cc: current@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch Message-ID: <20001122151221.A29341@dan.emsphone.com> References: <1050.974925641@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <1050.974925641@critter>; from "Poul-Henning Kamp" on Wed Nov 22 21:40:41 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Nov 22), Poul-Henning Kamp said: > The attached patch is a "proof-of-concept" on which I would like to > get some comments: > > It bugs me big time that the output from /etc/rc and all other output > to /dev/console is volatile and lost once it scrolls of your console. SCO logs its startup by simply piping the output of its rc scripts through "2>&1 | tee -a /usr/adm/rc#.log". We could do something similar by wrapping everything after the "mount -a -t nonfs" command on like 174 with { } 2>&1 | tee -a /var/log/boot.log -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 13:22:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 98CDF37B4CF; Wed, 22 Nov 2000 13:22:47 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eAMLMda01472; Wed, 22 Nov 2000 22:22:39 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Dan Nelson Cc: current@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch In-Reply-To: Your message of "Wed, 22 Nov 2000 15:12:22 CST." <20001122151221.A29341@dan.emsphone.com> Date: Wed, 22 Nov 2000 22:22:39 +0100 Message-ID: <1470.974928159@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001122151221.A29341@dan.emsphone.com>, Dan Nelson writes: >In the last episode (Nov 22), Poul-Henning Kamp said: >> The attached patch is a "proof-of-concept" on which I would like to >> get some comments: >> >> It bugs me big time that the output from /etc/rc and all other output >> to /dev/console is volatile and lost once it scrolls of your console. > >SCO logs its startup by simply piping the output of its rc scripts >through "2>&1 | tee -a /usr/adm/rc#.log". We could do something >similar by wrapping everything after the "mount -a -t nonfs" command on >like 174 with I've tried stuff like that and I didn't particularly like the result, for one thing many programs (or maybe it was tee(1) itself) changed buffering because of the pipe, which meant that the partial lines like "starting standard daemons: inetd cron sendmail sshd." would only arrive on the real console when the final \n arrived. Another particular thing I remember was that some syslog-challenged daemons whine on /dev/console long after /etc/rc has finished. Dump(8) will do something similar if you don't flip the tapes in finite time. So while it goes a long way, I think we need to provide more coverage of "/dev/console" as a concept. Poul-Henning PS: As I said, a decently functional console subsystem would be a nice thing. At the very least I would want to be able to specify: console output to /dev/ttyd0, /dev/ttyv0 and /var/log/console console input from /dev/ttyd0 or /dev/ttyv0. and preferably with a scrollback buffer too. Network consoles would be nice as well. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 13:34:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9BD9937B479; Wed, 22 Nov 2000 13:34:47 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAMLYLb23588; Wed, 22 Nov 2000 13:34:21 -0800 (PST) Date: Wed, 22 Nov 2000 13:34:21 -0800 From: Alfred Perlstein To: John Baldwin Cc: Daniel Eischen , Arun Sharma , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs Message-ID: <20001122133421.S18037@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Wed, Nov 22, 2000 at 01:06:04PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [001122 13:06] wrote: > > Eh, I would use a small LDT (LDT's don't have to be large if you don't have a > lot of selectors) for each KSE with one statically configured selector that %gs > is always set to that will point to the KSE data. Thus, when you create a KSE, > you just setup its LDT to have the KSE data entry point to the KSE data. Was there something wrong with the suggestion to put the local info on the stack? I just don't see it being discussed at all. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 13:37:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 3896A37B4C5 for ; Wed, 22 Nov 2000 13:37:12 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id OAA02388; Wed, 22 Nov 2000 14:36:02 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpdAAAr0aate; Wed Nov 22 14:35:44 2000 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id OAA03830; Wed, 22 Nov 2000 14:36:32 -0700 (MST) From: Terry Lambert Message-Id: <200011222136.OAA03830@usr07.primenet.com> Subject: Re: Does this sound good? (Fwd: Re: passwd file update functions) To: julian@elischer.org (Julian Elischer) Date: Wed, 22 Nov 2000 21:36:31 +0000 (GMT) Cc: opentrax@email.com, arch@FreeBSD.ORG In-Reply-To: <3A1AE456.9F883FE3@elischer.org> from "Julian Elischer" at Nov 21, 2000 01:08:38 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > the passwd file update functions in "libutil" don't support using a > > > directory other than "/etc" for the password database. I would like > > > to add a new function "pw_prefix(3)" which can be used to set the > > > prefix. This function could e.g. be used to enhance "vipw" and > > > "rpc.yppasswdd" to work with directories != "/etc". > > that would be good for Whistle, though by now we have (well, they have) > workarounds for the fact that / is read-only.. mostly symlinks. I already use a non-default location for initally setting the root password in jails created by a creation script I have written. If you look at the "pw" command, you'll see it can take a location other than the default for these files. If you just use the same mechanism elsewhere, you can get the same effect; IMO, it's just missing functionality in the passwd and similar commands. PS: I had to use "pw" because passwd stupidly insists on being interactive. I guess it's "protecting" me from getting my work done ...er, from shooting my foot. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 14: 6:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 1AB1E37B479; Wed, 22 Nov 2000 14:06:39 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id PAA23311; Wed, 22 Nov 2000 15:02:56 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpdAAAnCaGrT; Wed Nov 22 15:02:45 2000 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id PAA04455; Wed, 22 Nov 2000 15:06:15 -0700 (MST) From: Terry Lambert Message-Id: <200011222206.PAA04455@usr07.primenet.com> Subject: Re: Thread-specific data and KSEs To: eischen@vigrid.com (Daniel Eischen) Date: Wed, 22 Nov 2000 22:06:15 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), jhb@FreeBSD.ORG (John Baldwin), jlemon@flugsvamp.com (Jonathan Lemon), arch@FreeBSD.ORG In-Reply-To: from "Daniel Eischen" at Nov 21, 2000 10:15:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > >> %fs and %gs, but no other seg regs. > > > > > > > > All I need is one. > > > > > > Well, %gs would cover x86 and k64. I think ia64 has several > > > application registers that are available for OS use and we > > > could steal one of those. I'm not sure about the alpha though. > > > > Don't more segment registers cause more overhead for context switches? > > It's just one more register that has to be saved. I don't > think it's going to matter much. The %gs register already has to be saved for WINE processes, so it's taken (at least when USER_LDT is defined). So there would not be an additional context switch for it. I think that if you guys go forward with this, you should do an indirect through whatever you end up using. I realize this will cost an additional 6 clock cycles, but it will let you expand the list of things indefinitely, going forward, instead of having to keep a register dedicated for backward compatability, and then somehow "grow a new one" when you need to do something similar to this again, in the future. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 14:13:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 7C23E37B479 for ; Wed, 22 Nov 2000 14:13:21 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAMMDC059172; Wed, 22 Nov 2000 14:13:12 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011222206.PAA04455@usr07.primenet.com> Date: Wed, 22 Nov 2000 14:13:24 -0800 (PST) From: John Baldwin To: Terry Lambert Subject: Re: Thread-specific data and KSEs Cc: arch@FreeBSD.org, (Jonathan Lemon) , (Alfred Perlstein) , (Daniel Eischen) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Terry Lambert wrote: >> > > >> %fs and %gs, but no other seg regs. >> > > > >> > > > All I need is one. >> > > >> > > Well, %gs would cover x86 and k64. I think ia64 has several >> > > application registers that are available for OS use and we >> > > could steal one of those. I'm not sure about the alpha though. >> > >> > Don't more segment registers cause more overhead for context switches? >> >> It's just one more register that has to be saved. I don't >> think it's going to matter much. > > The %gs register already has to be saved for WINE processes, > so it's taken (at least when USER_LDT is defined). So there > would not be an additional context switch for it. Ok. Since %fs is only used in the kernel and is saved/restored it might be a good thing to use instead. > I think that if you guys go forward with this, you should do an > indirect through whatever you end up using. I realize this will > cost an additional 6 clock cycles, but it will let you expand > the list of things indefinitely, going forward, instead of having > to keep a register dedicated for backward compatability, and then > somehow "grow a new one" when you need to do something similar to > this again, in the future. It will be an indirect if I have any say in it. :) Currently we use %fs in the kernel to address a segment that contains per-CPU data. I think that if we use a seg reg, then we should have it address a segment that contains per-KSE data. > Terry Lambert > terry@lambert.org -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 14:13:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 1E08437B4F9 for ; Wed, 22 Nov 2000 14:13:25 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAMMDB059168; Wed, 22 Nov 2000 14:13:11 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001122133421.S18037@fw.wintelcom.net> Date: Wed, 22 Nov 2000 14:13:23 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: Thread-specific data and KSEs Cc: arch@FreeBSD.org, Arun Sharma , Daniel Eischen Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Alfred Perlstein wrote: > * John Baldwin [001122 13:06] wrote: >> >> Eh, I would use a small LDT (LDT's don't have to be large if you don't have >> a >> lot of selectors) for each KSE with one statically configured selector that >> %gs >> is always set to that will point to the KSE data. Thus, when you create a >> KSE, >> you just setup its LDT to have the KSE data entry point to the KSE data. > > Was there something wrong with the suggestion to put the local info > on the stack? I just don't see it being discussed at all. No, I was just exploring the possibility of the original request of using a register to do it. Using the stack may not be bad idea, although using a register would be more consistent with how we treat per-CPU data in the kernel. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 15: 7:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 00E2937B479; Wed, 22 Nov 2000 15:07:49 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA08419; Wed, 22 Nov 2000 18:07:27 -0500 (EST) Date: Wed, 22 Nov 2000 18:07:27 -0500 (EST) From: Daniel Eischen To: Alfred Perlstein Cc: John Baldwin , Arun Sharma , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: <20001122133421.S18037@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 22 Nov 2000, Alfred Perlstein wrote: > * John Baldwin [001122 13:06] wrote: > > > > Eh, I would use a small LDT (LDT's don't have to be large if you don't have a > > lot of selectors) for each KSE with one statically configured selector that %gs > > is always set to that will point to the KSE data. Thus, when you create a KSE, > > you just setup its LDT to have the KSE data entry point to the KSE data. > > Was there something wrong with the suggestion to put the local info > on the stack? I just don't see it being discussed at all. Yes, I stated that it could not be used. We want to provide a POSIX complaint API, and this dictates that applications be able to create stacks of their own size and choosing. We can't rely on stacks being any particular size, or starting at any particular address. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 15:17:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 1B17037B479; Wed, 22 Nov 2000 15:17:53 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA09565; Wed, 22 Nov 2000 18:17:30 -0500 (EST) Date: Wed, 22 Nov 2000 18:17:30 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Alfred Perlstein , John Baldwin , Jonathan Lemon , arch@FreeBSD.ORG Subject: Re: Thread-specific data and KSEs In-Reply-To: <200011222206.PAA04455@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 22 Nov 2000, Terry Lambert wrote: > > > > >> %fs and %gs, but no other seg regs. > > > > > > > > > > All I need is one. > > > > > > > > Well, %gs would cover x86 and k64. I think ia64 has several > > > > application registers that are available for OS use and we > > > > could steal one of those. I'm not sure about the alpha though. > > > > > > Don't more segment registers cause more overhead for context switches? > > > > It's just one more register that has to be saved. I don't > > think it's going to matter much. > > The %gs register already has to be saved for WINE processes, > so it's taken (at least when USER_LDT is defined). So there > would not be an additional context switch for it. Are WINE processes threaded? Do we really care? > I think that if you guys go forward with this, you should do an > indirect through whatever you end up using. I realize this will > cost an additional 6 clock cycles, but it will let you expand > the list of things indefinitely, going forward, instead of having > to keep a register dedicated for backward compatability, and then > somehow "grow a new one" when you need to do something similar to > this again, in the future. If you have an API in mind, send it to me. "current thread" is used an awful lot in the threads library and I'd like to avoid any uncessary levels of indirection, which is one reason I'd like to do it the way jhb suggested. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 15:29: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id EFF1237B4C5; Wed, 22 Nov 2000 15:28:57 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA10922; Wed, 22 Nov 2000 18:28:38 -0500 (EST) Date: Wed, 22 Nov 2000 18:28:38 -0500 (EST) From: Daniel Eischen To: John Baldwin Cc: Terry Lambert , arch@FreeBSD.ORG, jlemon@flugsvamp.com, bright@wintelcom.net Subject: Re: Thread-specific data and KSEs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 22 Nov 2000, John Baldwin wrote: > > On 22-Nov-00 Terry Lambert wrote: > > The %gs register already has to be saved for WINE processes, > > so it's taken (at least when USER_LDT is defined). So there > > would not be an additional context switch for it. > > Ok. Since %fs is only used in the kernel and is saved/restored it might be a > good thing to use instead. I didn't think %fs was saved, but if it is, that's fine with me too. > > I think that if you guys go forward with this, you should do an > > indirect through whatever you end up using. I realize this will > > cost an additional 6 clock cycles, but it will let you expand > > the list of things indefinitely, going forward, instead of having > > to keep a register dedicated for backward compatability, and then > > somehow "grow a new one" when you need to do something similar to > > this again, in the future. > > It will be an indirect if I have any say in it. :) Currently we use %fs in the > kernel to address a segment that contains per-CPU data. I think that if we use > a seg reg, then we should have it address a segment that contains per-KSE data. Didn't Terry want an additional level of indirection? If we have %fs address a segment containing per-KSE data, then I'd like to place pointers to both the KSE struct and the thread struct (2 slots) in this segment (this would remove 1 level of indirection to "current thread"). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 22 16: 4:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 7CB5A37B4CF for ; Wed, 22 Nov 2000 16:04:19 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eAN03uW03917; Wed, 22 Nov 2000 16:03:56 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 22 Nov 2000 16:04:02 -0800 (PST) From: John Baldwin To: Daniel Eischen Subject: Re: Thread-specific data and KSEs Cc: bright@wintelcom.net, jlemon@flugsvamp.com, arch@FreeBSD.org, Terry Lambert Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Nov-00 Daniel Eischen wrote: > On Wed, 22 Nov 2000, John Baldwin wrote: >> >> On 22-Nov-00 Terry Lambert wrote: >> > The %gs register already has to be saved for WINE processes, >> > so it's taken (at least when USER_LDT is defined). So there >> > would not be an additional context switch for it. >> >> Ok. Since %fs is only used in the kernel and is saved/restored it might be >> a >> good thing to use instead. > > I didn't think %fs was saved, but if it is, that's fine > with me too. Hmm, if it isn't it is trivial to save it. >> > I think that if you guys go forward with this, you should do an >> > indirect through whatever you end up using. I realize this will >> > cost an additional 6 clock cycles, but it will let you expand >> > the list of things indefinitely, going forward, instead of having >> > to keep a register dedicated for backward compatability, and then >> > somehow "grow a new one" when you need to do something similar to >> > this again, in the future. >> >> It will be an indirect if I have any say in it. :) Currently we use %fs in >> the >> kernel to address a segment that contains per-CPU data. I think that if we >> use >> a seg reg, then we should have it address a segment that contains per-KSE >> data. > > Didn't Terry want an additional level of indirection? If we > have %fs address a segment containing per-KSE data, then I'd > like to place pointers to both the KSE struct and the thread struct > (2 slots) in this segment (this would remove 1 level of indirection > to "current thread"). %fs is the indirection. :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 23 4:59:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by hub.freebsd.org (Postfix) with ESMTP id 1C48F37B479; Thu, 23 Nov 2000 04:59:15 -0800 (PST) Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout0.freenet.de with esmtp (Exim 3.16 #20) id 13yvy0-0005wZ-00; Thu, 23 Nov 2000 13:59:08 +0100 Received: from a38b1.pppool.de ([213.6.56.177] helo=Magelan.Leidinger.net) by mx1.freenet.de with esmtp (Exim 3.16 #20) id 13yvxw-0006Rz-00; Thu, 23 Nov 2000 13:59:06 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.1/8.11.1) with ESMTP id eANC70202422; Thu, 23 Nov 2000 13:07:01 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200011231207.eANC70202422@Magelan.Leidinger.net> Date: Thu, 23 Nov 2000 13:06:58 +0100 (CET) From: Alexander Leidinger Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch To: ashp@unloved.org Cc: phk@FreeBSD.ORG, current@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: <20001122215852.A75332@kyra.unloved.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22 Nov, Ashley Penney wrote: >> The attached patch is a "proof-of-concept" on which I would like >> to get some comments: > > I'm only a moronic user, but this would make my life easier. My machine > switches into 132x43 on startup, and I always lose the output. So this Its in the scrollback buffer. BTW: are you using a recent -current on an UP machine? After the first SMPNG commits the switch to 132x60 caused a hang on my machine and I haven't tested if this still happens. > is just me saying "Yay for phk." Yes. Regarding the "syslog writes messages back to /dev/console" thing: isn't this just a "I want to be able to shoot in my own foot" bikeshed? Bye, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 23 7: 4:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from spammie.svbug.com (mg134-015.ricochet.net [204.179.134.15]) by hub.freebsd.org (Postfix) with ESMTP id 4FBFB37B4C5 for ; Thu, 23 Nov 2000 07:04:19 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id HAA02178; Thu, 23 Nov 2000 07:04:04 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200011231504.HAA02178@spammie.svbug.com> Date: Thu, 23 Nov 2000 07:04:03 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... To: mbendiks@eunet.no Cc: arch@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15 Nov, Marius Bendiksen wrote: >> Would anyone have a heart attack if we removed I386_CPU from GENERIC but >> did not remove the 386 code? > > Not really; a 386 will usually require custom installation options anyway. > However, I'd appreciate if an installation floppy with just 386/486 could > be shipped on the side, stripped of those things not needed for those > people. That would resolve the problem nicely. > I'm wondering about your "custom installation". How does that relate to the question? Also you're inferring some type of new system, could you be more explict on this? Jessem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 23 11: 4:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 8309D37B4C5; Thu, 23 Nov 2000 11:04:14 -0800 (PST) Received: from pretoria-31.budapest.interware.hu ([195.70.53.95] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13z1f9-0004Eo-00; Thu, 23 Nov 2000 20:04:03 +0100 Message-ID: <3A1D6A19.801BBFA5@elischer.org> Date: Thu, 23 Nov 2000 11:03:53 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Thread-specific data and KSEs References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 22-Nov-00 Terry Lambert wrote: > > > > The %gs register already has to be saved for WINE processes, > > so it's taken (at least when USER_LDT is defined). So there > > would not be an additional context switch for it. > > Ok. Since %fs is only used in the kernel and is saved/restored it might be a > good thing to use instead. OK so let's do a little kernel code inspection..... first let's look at where the regs are saved.. the trapframe looks as follows (frame.h) slightly cut down ([...]) System calls are treated as a trap. This should be a good starting point. /* * Exception/Trap Stack Frame */ struct trapframe { int tf_fs; int tf_es; int tf_ds; [...] int tf_cs; int tf_eflags; /* below only when crossing rings (e.g. user to kernel) */ int tf_esp; int tf_ss; }; /* Superset of trap frame, for traps from virtual-8086 mode */ struct trapframe_vm86 { int tf_fs; int tf_es; int tf_ds; [...] int tf_cs; int tf_eflags; /* below only when crossing rings (e.g. user to kernel) */ int tf_esp; int tf_ss; /* below only when switching out of VM86 mode */ int tf_vm86_es; int tf_vm86_ds; int tf_vm86_fs; int tf_vm86_gs; }; /* Interrupt stack frame */ struct intrframe { int if_vec; int if_fs; int if_es; int if_ds; [...] /* below portion defined in 386 hardware */ int if_eip; int if_cs; int if_eflags; /* below only when crossing rings (e.g. user to kernel) */ int if_esp; int if_ss; }; /* frame of clock (same as interrupt frame) */ struct clockframe { int cf_vec; int cf_fs; int cf_es; int cf_ds; [...] int cf_cs; int cf_eflags; /* below only when crossing rings (e.g. user to kernel) */ int cf_esp; int cf_ss; }; So, as you see, there is space for %fs to be saved, but in general, no place for %gs (except in th VM86 case). This kinda suggests that %fs is the way to go. (so far it appears that %gs can't be in use at the moment). In signal.h the osigcontext looks like: (showing only segment regs) truct osigcontext { int sc_onstack; /* sigstack state to restore */ osigset_t sc_mask; /* signal mask to restore */ [...] int sc_es; int sc_ds; int sc_cs; int sc_ss; [...] int sc_gs; int sc_fs; int sc_trapno; int sc_err; }; which has places for both %gs and %fs Similarly the new sigcontext given to the process is: /* * The sequence of the fields/registers in struct sigcontext should match * those in mcontext_t. */ struct sigcontext { sigset_t sc_mask; /* signal mask to restore */ int sc_onstack; /* sigstack state to restore */ int sc_gs; /* machine state (struct trapframe): */ int sc_fs; int sc_es; int sc_ds; [...] int sc_cs; int sc_efl; int sc_esp; int sc_ss; [...] }; Once again both %gs and %fs are supported. so, signals should be able to cope with either. reg.h shows what /proc supports (both f and g) proc.h includes a trapframe (see above) via machine/proc.h so the proc structure (and this the KSEC eventually) hold %f but not %g In trap.c there is the following code that might have to be understood for this to work: void trap(frame) { [...] if ((ISPL(frame.tf_cs) == SEL_UPL) || ((frame.tf_eflags & PSL_VM) && !in_vm86call)) { /* user trap */ [...] } else { /* kernel trap */ [...] case T_SEGNPFLT: /* segment not present fault */ if (in_vm86call) break; if (intr_nesting_level != 0) break; /* * Invalid %fs's and %gs's can be created using * procfs or PT_SETREGS or by invalidating the * underlying LDT entry. This causes a fault * in kernel mode when the kernel attempts to * switch contexts. Lose the bad context * (XXX) so that we can continue, and generate * a signal. */ if (frame.tf_eip == (int)cpu_switch_load_gs) { curpcb->pcb_gs = 0; psignal(p, SIGBUS); goto out; } I notice that %fs is not touched.. (maybe it's fixed elsewhere) but this suggests that %gs and %fs are being loaded or the fault wouldn't happen. So where is %gs being loaded from..? in proc.h the proc structure includes: struct mdproc p_md; /* Any machine-dependent fields. */ which from i386/include/proc.h is: struct mdproc { struct trapframe *md_regs; /* registers on current frame */ }; which as we see above does not include room for %gs, however This appears misleading, because the structure 'pcb' in i386/include/pcb.h does include a field for %gs. A pointer to the current pcb is part of the per-CPU global data in globals.h. It is in user.h and as such is in the user structure. which is pointed to by p_addr in the proc structure. And lo-and-behold, there it is... a place to store the %gs register as well. (Why it's not in the proc structure I don't follow) Swtch.s seems to save it nicely with: movl %gs,PCB_GS(%edx) and I'm sure that %fs is similarly saved (It's on the stack) So it looks like you should be able to go ahead and use those registers. We will need to duplicate the U-area for KSEs anyhow so assuming that, both regs would be ok. Interestingly they use %fs in kernel, but in fact since they have a Per-CPU 4MB range of memory now (where each CPU sees different physical pages at the same address, it would now be possible for the kernel to drop this.. at the moment they are using %fs AND mapping, so in fact they are mapping twice. This brings up a possibility that if they have to fiddle the page maps for each KSE anyhow (to put the different PDE in,) they could just as easily fiddle TWO entries and give us a 4K or 4MB (take your pick) KSE dependent region within the use space. That would not require ANY registers. The trick would be to put a different PTE in for each KSE in the top page table just above the orogonal stack. The top page table must already there and loaded because the stack is in it. The trouble with this idea is that it would require having code to keep the rest of the PTEs (in the other KSEs Page tables) all in sync. You could make the kernel take 4MB from each address space, and put the stack (etc) below that and make it illegal to map new pages into that region. that way the kernel would only have to keep track of the single Page it allocates into that space per KSE. (The VM would have to be in on that act.. yech) Or alternatively, you could allow the user to access a page in the existing PER_CPU region (yeah I know it's at teh top of memory, above where the user process can usually touch, but we could set a segment up there, and allow it to get to it. You'd get a 4K window at 0xffaxx000 or somewhere. > > I think that if you guys go forward with this, you should do an > > indirect through whatever you end up using. I realize this will > > cost an additional 6 clock cycles, but it will let you expand > > the list of things indefinitely, going forward, instead of having > > to keep a register dedicated for backward compatability, and then > > somehow "grow a new one" when you need to do something similar to > > this again, in the future. > > It will be an indirect if I have any say in it. :) Currently we use %fs in the > kernel to address a segment that contains per-CPU data. I think that if we use > a seg reg, then we should have it address a segment that contains per-KSE data. For now I think that %fs is definitly safe.. and if you use it it could be used as the entry into the per-KSE area I just mentionned. (with interestingly, the almost the same contents as the kernel uses.). > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 23 16: 8:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by hub.freebsd.org (Postfix) with SMTP id 4E3FD37B4D7 for ; Thu, 23 Nov 2000 16:08:47 -0800 (PST) Received: (qmail 11716671 invoked from network); 24 Nov 2000 00:08:45 -0000 Received: from s011.dhcp212-229.cybercable.fr (HELO gits.dyndns.org) ([212.198.229.11]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 24 Nov 2000 00:08:45 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.1/8.11.1) id eAO08gV30354; Fri, 24 Nov 2000 01:08:42 +0100 (CET) (envelope-from clefevre@cybercable.fr) Original-Sender: Cyrille Lefevre Original-Sender: Cyrille Lefevre To: Alexander Leidinger Cc: ashp@unloved.org, phk@FreeBSD.ORG, current@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch References: <200011231207.eANC70202422@Magelan.Leidinger.net> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C In-Reply-To: Alexander Leidinger's message of "Thu, 23 Nov 2000 13:06:58 +0100 (CET)" From: Cyrille Lefevre Reply-To: Cyrille Lefevre Mail-Copies-To: never Date: 24 Nov 2000 01:08:37 +0100 Message-ID: <7l5umdtm.fsf@gits.dyndns.org> Lines: 18 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alexander Leidinger writes: > On 22 Nov, Ashley Penney wrote: > > >> The attached patch is a "proof-of-concept" on which I would like > >> to get some comments: > > > > I'm only a moronic user, but this would make my life easier. My machine > > switches into 132x43 on startup, and I always lose the output. So this > > Its in the scrollback buffer. and how do you access the scroll-back buffer if you are not front to the console (read remote) ? Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 23 17:56:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 3CCB637B479; Thu, 23 Nov 2000 17:56:54 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA16094; Thu, 23 Nov 2000 18:55:47 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAA5fa4zF; Thu Nov 23 18:55:44 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA06496; Thu, 23 Nov 2000 18:56:44 -0700 (MST) From: Terry Lambert Message-Id: <200011240156.SAA06496@usr06.primenet.com> Subject: Re: Thread-specific data and KSEs To: eischen@vigrid.com (Daniel Eischen) Date: Fri, 24 Nov 2000 01:56:44 +0000 (GMT) Cc: jhb@FreeBSD.ORG (John Baldwin), tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG, jlemon@flugsvamp.com, bright@wintelcom.net In-Reply-To: from "Daniel Eischen" at Nov 22, 2000 06:28:38 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The %gs register already has to be saved for WINE processes, > > > so it's taken (at least when USER_LDT is defined). So there > > > would not be an additional context switch for it. > > > > Ok. Since %fs is only used in the kernel and is saved/restored > > it might be a good thing to use instead. > > I didn't think %fs was saved, but if it is, that's fine > with me too. I think this misses the original point: if the register is supposed to be a rendesvous between user and kernel space, it needs to be the same in kernel space, not "saved and changed". I think that %fs and %gs are saved, but not preserved in the kernel: they are per process. This may be enough, if the reload is done late enough, but it may not. After a wakeup, prior to an upcall, a KSE would need to have this value restored to its pre-sleep state; as pointed out in this thread already (first by Arun?), this may be too expensive. In fact, since the stack needs to be reloaded anyway, I'm partial to Alfred's suggestion, even though it makes stack length less determinate than it already is (the big drawback to Alfred's suggestion). > > It will be an indirect if I have any say in it. :) Currently > > we use %fs in the kernel to address a segment that contains > > per-CPU data. I think that if we use a seg reg, then we > > should have it address a segment that contains per-KSE data. > > Didn't Terry want an additional level of indirection? If we > have %fs address a segment containing per-KSE data, then I'd > like to place pointers to both the KSE struct and the thread struct > (2 slots) in this segment (this would remove 1 level of indirection > to "current thread"). I wanted the additional evel of indirection so that the next good reason gfor grabing %gs (or %fs) won't result in being impossible to implement. This means that I think the register should be associated with the most granular scheduling unit, and point to a table of values, the first element of which is whatever you guys are wanting to put in a register right now. This is an additional indirection, but it means that the next time someone needs some way to squirrel away data, it will be there, instead of being impossible without a large rewrite. The initial length of this table could be "one element". As your element would be the first element, there is no addition required to access it, so it's a direct dereference of the first element (a double dereference of the register), or an extra 6 cycles, according to the programming manual here... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 23 18: 8:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 7CC5C37B4C5; Thu, 23 Nov 2000 18:08:53 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id TAA18429; Thu, 23 Nov 2000 19:07:49 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAK0a46J; Thu Nov 23 19:07:39 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA06691; Thu, 23 Nov 2000 19:08:40 -0700 (MST) From: Terry Lambert Message-Id: <200011240208.TAA06691@usr06.primenet.com> Subject: Re: Thread-specific data and KSEs To: eischen@vigrid.com (Daniel Eischen) Date: Fri, 24 Nov 2000 02:08:40 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), jhb@FreeBSD.ORG (John Baldwin), jlemon@flugsvamp.com (Jonathan Lemon), arch@FreeBSD.ORG In-Reply-To: from "Daniel Eischen" at Nov 22, 2000 06:17:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The %gs register already has to be saved for WINE processes, > > so it's taken (at least when USER_LDT is defined). So there > > would not be an additional context switch for it. > > Are WINE processes threaded? Do we really care? You probably don't care, but in Windows programs, the code is the same for all event sinks, and it's the %gs register which is used to get the data segment context. In WIN32, this is basically a "thread ID". In Windows with multiple instances of the same program, the data segment is the "program ID", and it's how programs differentiate from each other when sending events, etc., and how the OS does the same. You probably don't care because it only means that the register is saved and restored on a per process basis already, and can't really be used with an indirect, due to the assumptions of WINE. You could implement a double indirect going to user space, but you would need to store a copy of the table pointer in the proc struct, and then dereference whatever element was the "WINE %gs" element for WINE processes going back to user space. As a general mechanism, you could dereference the thread element going back to a threaded program in user space; this is somewhat gross, in that it means that you would only get one element per applcpiation domain, instead of as many as you wanted, and you would have to recognize the application domain from kernel space (but you would have to do this anyway, for WINE programs). This kind of hints at either a general mechanism, or a different register and a general mechanism, to avoid conflict with WINE. In the second case, you could leave the table reference intact going to user space, and it would make the interface reflexive, and not limit you to one element (or put another way, your application could be in more than one application domain at the same time, using this approach). > If you have an API in mind, send it to me. "current thread" is > used an awful lot in the threads library and I'd like to avoid > any uncessary levels of indirection, which is one reason I'd > like to do it the way jhb suggested. I think you should do the extra indirect, because you can't tell what the future will bring in terms of people needing to communicate per scheduling entity information around. I would go so far as to suggest that the per CPU stuff should probably be similarly abstracted, to allow for future uses which we haven't considered yet there, either. Worst case, the architecture specific data could be seperated. I suspect that someone, somewhere, is working on an OS like the one at the University of Utah, using source code to migrate processes between dissimilar architectures (as one over-the-top example). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 23 23:28: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 28D3337B4C5 for ; Thu, 23 Nov 2000 23:28:04 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 3D7B8C7B for ; Thu, 23 Nov 2000 23:28:03 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id XAA24707 for ; Thu, 23 Nov 2000 23:28:02 -0800 (PST) Message-ID: <3A1E1882.38BB37FA@cup.hp.com> Date: Thu, 23 Nov 2000 23:28:02 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.org Subject: RQ review: sigaltstack changes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Problem description: The kernel maintains state about whether the process is on the alternate stack or not. This state information is invalidated when the process switches from the alternate stack by means other than a sigreturn. Solution: The kernel determines whether the process is on the alternate stack or not by testing if the stack pointer is within the range of the alternate stack if such is defined. The p_sigstk.ss_flags variable is only used for backward compatibility. Patch: ftp://ftp.cup.hp.com/dist/marcel/sig.diff PR: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22286 With the fix, the trigger case in the PR works without work-around. Your comments, -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 24 9:50:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id 2C2FA37B479; Fri, 24 Nov 2000 09:50:53 -0800 (PST) Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtp (Exim 3.16 #20) id 13zMzq-000807-00; Fri, 24 Nov 2000 18:50:50 +0100 Received: from a318d.pppool.de ([213.6.49.141] helo=Magelan.Leidinger.net) by mx1.freenet.de with esmtp (Exim 3.16 #20) id 13zMzm-0004pJ-00; Fri, 24 Nov 2000 18:50:47 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.1/8.11.1) with ESMTP id eAOGdOE06364; Fri, 24 Nov 2000 17:39:25 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200011241639.eAOGdOE06364@Magelan.Leidinger.net> Date: Fri, 24 Nov 2000 17:39:23 +0100 (CET) From: Alexander Leidinger Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch To: clefevre@cybercable.fr Cc: ashp@unloved.org, current@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: <7l5umdtm.fsf@gits.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24 Nov, Cyrille Lefevre wrote: >> >> The attached patch is a "proof-of-concept" on which I would like >> >> to get some comments: >> > >> > I'm only a moronic user, but this would make my life easier. My machine >> > switches into 132x43 on startup, and I always lose the output. So this >> >> Its in the scrollback buffer. > > and how do you access the scroll-back buffer if you are not front to the > console (read remote) ? You can't. I didn't see the relationship between my answer to Ashley and your question, can you please give me a hint? Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 25 7:41:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id AD10937B4C5; Sat, 25 Nov 2000 07:41:09 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA02819; Sat, 25 Nov 2000 07:41:03 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda02817; Sat Nov 25 07:40:56 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAPFepI56547; Sat, 25 Nov 2000 07:40:51 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdx56544; Sat Nov 25 07:40:05 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAPFe4N00849; Sat, 25 Nov 2000 07:40:04 -0800 (PST) Message-Id: <200011251540.eAPFe4N00849@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdPDY837; Sat Nov 25 07:39:33 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.2-RELEASE X-Sender: cy To: Poul-Henning Kamp Cc: current@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch In-reply-to: Your message of "Wed, 22 Nov 2000 21:40:41 +0100." <1050.974925641@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Nov 2000 07:39:33 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <1050.974925641@critter>, Poul-Henning Kamp writes: > > The attached patch is a "proof-of-concept" on which I would like > to get some comments: > > It bugs me big time that the output from /etc/rc and all other output > to /dev/console is volatile and lost once it scrolls of your console. It's a no-brainer. Let's do it. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 25 11:27:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (unknown [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id B76DB37B4D7; Sat, 25 Nov 2000 11:27:54 -0800 (PST) Received: from berserker.bsdi.com (cp@localhost.bsdi.com [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id MAA17860; Sat, 25 Nov 2000 12:27:54 -0700 (MST) (envelope-from cp@berserker.bsdi.com) Message-Id: <200011251927.MAA17860@berserker.bsdi.com> To: Poul-Henning Kamp Cc: current@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch In-reply-to: Your message of "Wed, 22 Nov 2000 21:40:41 +0100." <1050.974925641@critter> From: Chuck Paterson Date: Sat, 25 Nov 2000 12:27:54 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there reason to believe that we won't have dead lock problems from the M_WAITOK? It seems like that if anything in the path needed to full fill the malloc needs to log there is a problem. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 25 12:26:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id D459737B479; Sat, 25 Nov 2000 12:26:09 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eAPKQ2T20475; Sat, 25 Nov 2000 21:26:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Chuck Paterson Cc: current@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch In-Reply-To: Your message of "Sat, 25 Nov 2000 12:27:54 MST." <200011251927.MAA17860@berserker.bsdi.com> Date: Sat, 25 Nov 2000 21:26:02 +0100 Message-ID: <20473.975183962@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011251927.MAA17860@berserker.bsdi.com>, Chuck Paterson writes: > > Is there reason to believe that we won't have dead lock >problems from the M_WAITOK? It seems like that if anything in >the path needed to full fill the malloc needs to log there >is a problem. We don't otherwise treat the /dev/console file descriptor magically. Think about ktracing a process which writes to /dev/console, debugging it and so on... One can successfully argue that the relationship between the console device and syslogd is needlessly incestous but until somebody restructures the console code to be more sanely (or even just at all) layered that is a "Sigh.. wouldn't it be nice if..." kind of item. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 25 19:13:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by hub.freebsd.org (Postfix) with SMTP id 2200A37B4D7 for ; Sat, 25 Nov 2000 19:13:34 -0800 (PST) Received: (qmail 71567 invoked from network); 26 Nov 2000 03:13:32 -0000 Received: from s011.dhcp212-229.cybercable.fr (HELO gits.dyndns.org) ([212.198.229.11]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 26 Nov 2000 03:13:32 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.1/8.11.1) id eAQ3DVN75472; Sun, 26 Nov 2000 04:13:31 +0100 (CET) (envelope-from clefevre@citeweb.net) Original-Sender: Cyrille Lefevre Original-Sender: Cyrille Lefevre To: Alexander Leidinger Cc: clefevre@cybercable.fr, ashp@unloved.org, current@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: /dev/console -> /var/log/messages idea/patch References: <200011241639.eAOGdOE06364@Magelan.Leidinger.net> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C Reply-To: Cyrille Lefevre In-Reply-To: Alexander Leidinger's message of "Fri, 24 Nov 2000 17:39:23 +0100 (CET)" From: Cyrille Lefevre Date: 26 Nov 2000 04:13:30 +0100 Message-ID: Lines: 27 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alexander Leidinger writes: > On 24 Nov, Cyrille Lefevre wrote: > > >> >> The attached patch is a "proof-of-concept" on which I would like > >> >> to get some comments: > >> > > >> > I'm only a moronic user, but this would make my life easier. My machine > >> > switches into 132x43 on startup, and I always lose the output. So this > >> > >> Its in the scrollback buffer. > > > > and how do you access the scroll-back buffer if you are not front to the > > console (read remote) ? > > You can't. > > I didn't see the relationship between my answer to Ashley and your > question, can you please give me a hint? I just want to say that I'm full about doing something which logs what's happen at boot time, and that the scrollback buffer isn't sufficient. in other words, something like PR#14931 until this work is commited. Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message