From owner-freebsd-smp Sun Oct 8 4:35:57 2000 Delivered-To: freebsd-smp@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 3151C37B503 for ; Sun, 8 Oct 2000 04:35:55 -0700 (PDT) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id MAA61661 for smp@freebsd.org; Sun, 8 Oct 2000 12:35:53 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id MAA84277 for ; Sun, 8 Oct 2000 12:05:13 +0100 (BST) (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 8 Oct 2000 12:05:12 +0100 To: smp@freebsd.org From: Bob Bishop Subject: Options with SMPng Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Apart from the basic SMP options, what kernel options should the conscientious SMPng tester be using right now? TIA -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Oct 8 19:59:43 2000 Delivered-To: freebsd-smp@freebsd.org Received: from smtp4.cbn.net.id (smtp4.cbn.net.id [202.158.2.54]) by hub.freebsd.org (Postfix) with ESMTP id C422C37B66E for ; Sun, 8 Oct 2000 19:59:40 -0700 (PDT) Received: from unga (unknown [202.158.50.87]) by smtp4.cbn.net.id (Postfix) with SMTP id 666425354C for ; Mon, 9 Oct 2000 10:01:27 +0700 (JAVT) Message-ID: <005401c0319c$92644d40$6201400a@int.cbn.net.id> From: "Said Madrus" To: Subject: subscribe Date: Mon, 9 Oct 2000 09:56:50 +0700 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.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Oct 8 23: 6:16 2000 Delivered-To: freebsd-smp@freebsd.org Received: from server.baldwin.cx (server.geekhouse.net [64.81.6.52]) by hub.freebsd.org (Postfix) with ESMTP id CE17337B503 for ; Sun, 8 Oct 2000 23:06:10 -0700 (PDT) Received: from john.baldwin.cx (root@john.baldwin.cx [192.168.1.18]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id XAA59518; Sun, 8 Oct 2000 23:10:16 -0700 (PDT) (envelope-from john@baldwin.cx) Received: (from john@localhost) by john.baldwin.cx (8.9.3/8.9.3) id XAA03206; Sun, 8 Oct 2000 23:07:52 -0700 (PDT) (envelope-from john) Message-Id: <200010090607.XAA03206@john.baldwin.cx> 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: Sun, 08 Oct 2000 23:07:52 -0700 (PDT) From: John Baldwin To: Bob Bishop Subject: RE: Options with SMPng Cc: smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 08-Oct-00 Bob Bishop wrote: > Hi, > > Apart from the basic SMP options, what kernel options should the > conscientious SMPng tester be using right now? TIA As mentioned on -current about 2-3 weeks ago: options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTICS options SMP_DEBUG (if you want the KTR tracing stuff:) options KTR options KTR_EXTEND options KTR_COMPILE=0x3fffff options KTR_MASK=(KTR_INTR|KTR_PROC) options KTR_ENTRIES=1024 # or some other power of 2 KTR is only useful during panics when you can dump the trace buffer, or if you are doiing remote kgdb, or ddb on a running 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-smp" in the body of the message From owner-freebsd-smp Mon Oct 9 2: 9:29 2000 Delivered-To: freebsd-smp@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 580F537B502; Mon, 9 Oct 2000 02:09:26 -0700 (PDT) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id KAA72684; Mon, 9 Oct 2000 10:09:25 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id JAA86939; Mon, 9 Oct 2000 09:47:28 +0100 (BST) (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <200010090607.XAA03206@john.baldwin.cx> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Oct 2000 09:47:28 +0100 To: John Baldwin From: Bob Bishop Subject: RE: Options with SMPng Cc: smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks, What about WITNESS? I'm checking these because KTR in particular increases the kenel size and I'm having trouble getting large kernels to boot (see thread "Recent kernels won't boot" on -current). At 23:07 -0700 8/10/00, John Baldwin wrote: >On 08-Oct-00 Bob Bishop wrote: >> Hi, >> >> Apart from the basic SMP options, what kernel options should the >> conscientious SMPng tester be using right now? TIA > >As mentioned on -current about 2-3 weeks ago: > >options INVARIANTS >options INVARIANT_SUPPORT >options DIAGNOSTICS >options SMP_DEBUG > >(if you want the KTR tracing stuff:) >options KTR >options KTR_EXTEND >options KTR_COMPILE=0x3fffff >options KTR_MASK=(KTR_INTR|KTR_PROC) >options KTR_ENTRIES=1024 # or some other power of 2 > >KTR is only useful during panics when you can dump the trace >buffer, or if you are doiing remote kgdb, or ddb on a running >kernel. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 9 7: 5: 1 2000 Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 4EC1F37B502; Mon, 9 Oct 2000 07:04:54 -0700 (PDT) Received: from berserker.bsdi.com (cp@localhost [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id HAA06839; Mon, 9 Oct 2000 07:40:56 -0600 (MDT) Message-Id: <200010091340.HAA06839@berserker.bsdi.com> To: John Baldwin Cc: Bob Bishop , smp@freebsd.org Subject: Re: Options with SMPng In-reply-to: Your message of "Sun, 08 Oct 2000 23:07:52 PDT." <200010090607.XAA03206@john.baldwin.cx> From: Chuck Paterson Date: Mon, 09 Oct 2000 07:40:56 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think we ought to dump the KTR_EXTEND stuff. This makes the kernel run soo slow that it isn't really usable. Without KTR_EXTEND the penalty is minor. John Baldwin wrote on: Sun, 08 Oct 2000 23:07:52 PDT } }(if you want the KTR tracing stuff:) }options KTR }options KTR_EXTEND }options KTR_COMPILE=0x3fffff }options KTR_MASK=(KTR_INTR|KTR_PROC) }options KTR_ENTRIES=1024 # or some other power of 2 } }KTR is only useful during panics when you can dump the trace }buffer, or if you are doiing remote kgdb, or ddb on a running }kernel. } }-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 9 9:37:52 2000 Delivered-To: freebsd-smp@freebsd.org Received: from server.baldwin.cx (server.geekhouse.net [64.81.6.52]) by hub.freebsd.org (Postfix) with ESMTP id 80F6737B66C for ; Mon, 9 Oct 2000 09:37:45 -0700 (PDT) Received: from john.baldwin.cx (root@john.baldwin.cx [192.168.1.18]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id JAA61342; Mon, 9 Oct 2000 09:41:48 -0700 (PDT) (envelope-from john@baldwin.cx) Received: (from john@localhost) by john.baldwin.cx (8.9.3/8.9.3) id JAA03990; Mon, 9 Oct 2000 09:39:43 -0700 (PDT) (envelope-from john) Message-Id: <200010091639.JAA03990@john.baldwin.cx> 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: <200010091340.HAA06839@berserker.bsdi.com> Date: Mon, 09 Oct 2000 09:39:43 -0700 (PDT) From: John Baldwin To: Chuck Paterson Subject: Re: Options with SMPng Cc: smp@freebsd.org, Bob Bishop Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 09-Oct-00 Chuck Paterson wrote: > I think we ought to dump the KTR_EXTEND stuff. This makes > the kernel run soo slow that it isn't really usable. Without > KTR_EXTEND the penalty is minor. Hmm, well, combined with my ktr-verbose hack, KTR_EXTEND's ability to print out a useful string directly has proved useful for tracking down bugs with interrupts disabled, or when, for example, PCI interrupts are firing too fast for any work to be done because the source wasn't being quieted on the alpha. > John Baldwin wrote on: Sun, 08 Oct 2000 23:07:52 PDT > } > }(if you want the KTR tracing stuff:) > }options KTR > }options KTR_EXTEND > }options KTR_COMPILE=0x3fffff > }options KTR_MASK=(KTR_INTR|KTR_PROC) > }options KTR_ENTRIES=1024 # or some other power of 2 > } > }KTR is only useful during panics when you can dump the trace > }buffer, or if you are doiing remote kgdb, or ddb on a running > }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-smp" in the body of the message From owner-freebsd-smp Mon Oct 9 19: 7:46 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 16D4037B503; Mon, 9 Oct 2000 19:07:41 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e9A27b787771; Tue, 10 Oct 2000 11:37:37 +0930 (CST) (envelope-from grog) Date: Tue, 10 Oct 2000 11:37:37 +0930 From: Greg Lehey To: John Baldwin Cc: Chuck Paterson , smp@FreeBSD.ORG, Bob Bishop Subject: Re: Options with SMPng Message-ID: <20001010113737.B87663@wantadilla.lemis.com> References: <200010091340.HAA06839@berserker.bsdi.com> <200010091639.JAA03990@john.baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010091639.JAA03990@john.baldwin.cx>; from jhb@FreeBSD.ORG on Mon, Oct 09, 2000 at 09:39:43AM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 9 October 2000 at 9:39:43 -0700, John Baldwin wrote: > > On 09-Oct-00 Chuck Paterson wrote: >> I think we ought to dump the KTR_EXTEND stuff. This makes >> the kernel run soo slow that it isn't really usable. Without >> KTR_EXTEND the penalty is minor. > > Hmm, well, combined with my ktr-verbose hack, KTR_EXTEND's ability > to print out a useful string directly has proved useful for tracking > down bugs with interrupts disabled, or when, for example, PCI interrupts > are firing too fast for any work to be done because the source wasn't > being quieted on the alpha. Agreed. Nobody's pretending that the KTR_EXTEND is useful in a general-purpose kernel, but it makes a lot of difference when developing. I don't see any good reason to dump it. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 9 19:25:25 2000 Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id C8F7337B503; Mon, 9 Oct 2000 19:25:22 -0700 (PDT) Received: from berserker.bsdi.com (cp@localhost [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id UAA11314; Mon, 9 Oct 2000 20:25:00 -0600 (MDT) Message-Id: <200010100225.UAA11314@berserker.bsdi.com> To: Greg Lehey Cc: John Baldwin , smp@freebsd.org, Bob Bishop Subject: Re: Options with SMPng In-reply-to: Your message of "Tue, 10 Oct 2000 11:37:37 +0930." <20001010113737.B87663@wantadilla.lemis.com> From: Chuck Paterson Date: Mon, 09 Oct 2000 20:25:00 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I realize that the implementation may currently cause this, but isn't the ktr_verbose really orthogonal to KTR_EXTEND. Perhaps my problem with KTR_EXTEND can be fixed by comments. There have been people trying to run with this because they thought this was the needed to get useful tracing. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 9 19:33:33 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 771BA37B502; Mon, 9 Oct 2000 19:33:28 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e9A2XPw88035; Tue, 10 Oct 2000 12:03:25 +0930 (CST) (envelope-from grog) Date: Tue, 10 Oct 2000 12:03:25 +0930 From: Greg Lehey To: John Baldwin , Chuck Paterson Cc: smp@FreeBSD.ORG, Bob Bishop Subject: Re: Options with SMPng Message-ID: <20001010120325.H87663@wantadilla.lemis.com> References: <20001010113737.B87663@wantadilla.lemis.com> <200010100225.UAA11314@berserker.bsdi.com> <200010091340.HAA06839@berserker.bsdi.com> <200010091639.JAA03990@john.baldwin.cx> <20001010113737.B87663@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001010113737.B87663@wantadilla.lemis.com>; from grog@lemis.com on Tue, Oct 10, 2000 at 11:37:37AM +0930 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 10 October 2000 at 11:37:37 +0930, Greg Lehey wrote: > On Monday, 9 October 2000 at 9:39:43 -0700, John Baldwin wrote: >> >> On 09-Oct-00 Chuck Paterson wrote: >>> I think we ought to dump the KTR_EXTEND stuff. This makes >>> the kernel run soo slow that it isn't really usable. Without >>> KTR_EXTEND the penalty is minor. >> >> Hmm, well, combined with my ktr-verbose hack, KTR_EXTEND's ability >> to print out a useful string directly has proved useful for tracking >> down bugs with interrupts disabled, or when, for example, PCI interrupts >> are firing too fast for any work to be done because the source wasn't >> being quieted on the alpha. > > Agreed. Nobody's pretending that the KTR_EXTEND is useful in a > general-purpose kernel, but it makes a lot of difference when > developing. I don't see any good reason to dump it. On Monday, 9 October 2000 at 20:25:00 -0600, Chuck Paterson wrote: > > I realize that the implementation may currently cause > this, but isn't the ktr_verbose really orthogonal to KTR_EXTEND. I'm not sure I understand the reference here. > Perhaps my problem with KTR_EXTEND can be fixed by > comments. There have been people trying to run with this because > they thought this was the needed to get useful tracing. Ah, that's a misunderstanding, of course. I'll take a look at the docco. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 9 23:26:58 2000 Delivered-To: freebsd-smp@freebsd.org Received: from echunga.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 2E42F37B503; Mon, 9 Oct 2000 23:26:43 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e973vqA28717; Sat, 7 Oct 2000 13:27:52 +0930 (CST) (envelope-from grog) Date: Sat, 7 Oct 2000 13:27:52 +0930 From: Greg Lehey To: Terry Lambert Cc: John Baldwin , Daniel Eischen , arch@FreeBSD.ORG, Alfred Perlstein , Mark Murray , Jake Burkholder , Boris Popov , freebsd-smp@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <20001007132752.A28665@wantadilla.lemis.com> References: <20001005113139.C27736@fw.wintelcom.net> <200010052142.OAA15421@usr05.primenet.com> <200009251938.MAA29311@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200009251938.MAA29311@usr02.primenet.com>; from tlambert@primenet.com on Mon, Sep 25, 2000 at 07:38:22PM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 25 September 2000 at 19:38:22 +0000, Terry Lambert wrote: >>> If we are going to support recursive mutex, I think it would be >>> better to add separate calls/macros/data types to support them, >>> so the the mtx mutexes can be simplified. Calls to mtx_enter >>> with the recursive mutex type wouldn't even compile. >> >> Err, the recursive nature of the mutexes is very trivial. It >> doesn't affect the complexity of the mutexes at all. > > Yes, it does. Ownership precludes hand-off. Recusrion support > implies permission and tacit approval. > > A mutex is not recursive. There are things you simply can not > implement when recursion is permitted for all of your primitives. > > The most obvious argument is still that a mutex is intended to > protect data, not code. Recursion is only required if the mutex > is actually protecting reentrancy of code, not access to data. On Thursday, 5 October 2000 at 21:42:28 +0000, Terry Lambert wrote: >>> There is another problem; printf's inside a kthread corrupt like >>> crazy. They look very unthreadsafe. >> >> do NOT use printf without Giant. > > This strikes me as being rather inane. > > If printf won't work without holging the lock, then it damn well > should acquire the lock if it isn't already held, and release it > if it acquired it, before returning. Make up your mind. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Oct 10 1:25:21 2000 Delivered-To: freebsd-smp@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 7125237B503; Tue, 10 Oct 2000 01:25:16 -0700 (PDT) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id BAA12092; Tue, 10 Oct 2000 01:23:38 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAAj8aGHx; Tue Oct 10 01:23:27 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id BAA13123; Tue, 10 Oct 2000 01:24:55 -0700 (MST) From: Terry Lambert Message-Id: <200010100824.BAA13123@usr06.primenet.com> Subject: Re: Mutexes and semaphores To: grog@lemis.com (Greg Lehey) Date: Tue, 10 Oct 2000 08:24:54 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), jhb@FreeBSD.ORG (John Baldwin), eischen@vigrid.com (Daniel Eischen), arch@FreeBSD.ORG, bright@wintelcom.net (Alfred Perlstein), mark@grondar.za (Mark Murray), jburkhol@home.com (Jake Burkholder), bp@butya.kz (Boris Popov), freebsd-smp@FreeBSD.ORG In-Reply-To: <20001007132752.A28665@wantadilla.lemis.com> from "Greg Lehey" at Oct 07, 2000 01:27:52 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-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > A mutex is not recursive. There are things you simply can not > > implement when recursion is permitted for all of your primitives. > > > > The most obvious argument is still that a mutex is intended to > > protect data, not code. Recursion is only required if the mutex > > is actually protecting reentrancy of code, not access to data. [ ... ] > >> do NOT use printf without Giant. > > > > This strikes me as being rather inane. > > > > If printf won't work without holging the lock, then it damn well > > should acquire the lock if it isn't already held, and release it > > if it acquired it, before returning. > > Make up your mind. I see no conflict. The printf should not fail unless it is the result of a data protection failure. Testing to see that the giant lock (which is not a mutex) is held, if it is truly a requirement to hold it, is not a problem. Acquiring the giant lock only if it is not already acquired, and only releasing it if it wre you who acquired it, is not recursion. Maybe I'm missing some subtlety here that you're not? 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-smp" in the body of the message From owner-freebsd-smp Tue Oct 10 1:46:38 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 0C8C537B503; Tue, 10 Oct 2000 01:46:31 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e9A8kL289653; Tue, 10 Oct 2000 18:16:21 +0930 (CST) (envelope-from grog) Date: Tue, 10 Oct 2000 18:16:21 +0930 From: Greg Lehey To: Terry Lambert Cc: John Baldwin , Daniel Eischen , arch@FreeBSD.ORG, Alfred Perlstein , Mark Murray , Jake Burkholder , Boris Popov , freebsd-smp@FreeBSD.ORG Subject: Re: Mutexes and semaphores Message-ID: <20001010181621.M87663@wantadilla.lemis.com> References: <20001007132752.A28665@wantadilla.lemis.com> <200010100824.BAA13123@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010100824.BAA13123@usr06.primenet.com>; from tlambert@primenet.com on Tue, Oct 10, 2000 at 08:24:54AM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tuesday, 10 October 2000 at 8:24:54 +0000, Terry Lambert wrote: >>> A mutex is not recursive. There are things you simply can not >>> implement when recursion is permitted for all of your primitives. >>> >>> The most obvious argument is still that a mutex is intended to >>> protect data, not code. Recursion is only required if the mutex >>> is actually protecting reentrancy of code, not access to data. I suppose I should have left this last paragraph of the quote out. The intention of mutexes is left to the programmer. While I agree that I'd rather use them to protect data than code, there's nothing in the nature of a mutex that requires that. >>>> do NOT use printf without Giant. >>> >>> This strikes me as being rather inane. >>> >>> If printf won't work without holging the lock, then it damn well >>> should acquire the lock if it isn't already held, and release it >>> if it acquired it, before returning. >> >> Make up your mind. > > I see no conflict. The printf should not fail unless it is > the result of a data protection failure. > > Testing to see that the giant lock (which is not a mutex) is > held, if it is truly a requirement to hold it, is not a problem. Giant is a mutex. > Acquiring the giant lock only if it is not already acquired, and > only releasing it if it wre you who acquired it, is not recursion. Well, for some definition of "recursion". I don't know if the term "recursive" is even appropriate for this behaviour. But if you find yourself in a position where you need to check whether you need to acquire a mutex, then "recursion" is the cheapest way to go. > Maybe I'm missing some subtlety here that you're not? Well, also that your alternative is even untidier than recursion. The whole original discussion boils down to "properly written code only needs to lock once". I tend to agree with this viewpoint, but it's clear that by that measure we have a lot of improperly written code. Recursion isn't the problem, it's the solution. You're advocating rejecting the solution ("because recursion is bad") and replacing it with a worse solution ("did we lock? OK, then we need to unlock now"). At the very least, that requires auxiliary variables which aren't part of the mutex, which is very untidy, especially if you have to debug the thing. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Oct 12 18: 9:21 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 631F737B66C; Thu, 12 Oct 2000 18:09:17 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e9D19EZ02578; Fri, 13 Oct 2000 10:39:14 +0930 (CST) (envelope-from grog) Date: Fri, 13 Oct 2000 10:39:14 +0930 From: Greg Lehey To: Jason Evans Cc: FreeBSD SMP list Subject: New mutexes (was: cvs commit: src/sys/conf param.c src/sys/kern kern_lock.c src/sys/sys kernel.h lock.h src/sys/vm vm_map.h) Message-ID: <20001013103913.B2467@wantadilla.lemis.com> References: <200010122237.PAA12428@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010122237.PAA12428@freefall.freebsd.org>; from jasone@FreeBSD.org on Thu, Oct 12, 2000 at 03:37:29PM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thursday, 12 October 2000 at 15:37:29 -0700, Jason Evans wrote: > jasone 2000/10/12 15:37:29 PDT > > Modified files: > sys/conf param.c > sys/kern kern_lock.c > sys/sys kernel.h lock.h > sys/vm vm_map.h > Log: > For lockmgr mutex protection, use an array of mutexes that are allocated > and initialized during boot. This avoids bloating sizeof(struct lock). > As a side effect, it is no longer necessary to enforce the assumtion that > lockinit()/lockdestroy() calls are paired, so the LK_VALID flag has been > removed. I'm just doing the slides for the Con, and going through the sources I note that we have sprouted a plethora of mutexes over the last month. How are we keeping track of them? How does somebody who wants to add a new mutex know where the mines are? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Oct 12 19: 5: 4 2000 Delivered-To: freebsd-smp@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 55D7937B502 for ; Thu, 12 Oct 2000 19:04:56 -0700 (PDT) Received: (qmail 20657 invoked by uid 1142); 13 Oct 2000 02:04:55 -0000 Date: 12 Oct 2000 19:04:55 -0700 Date: Thu, 12 Oct 2000 19:04:43 -0700 From: Jason Evans To: Greg Lehey Cc: FreeBSD SMP list Subject: Re: New mutexes Message-ID: <20001012190443.G11949@canonware.com> References: <200010122237.PAA12428@freefall.freebsd.org> <20001013103913.B2467@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001013103913.B2467@wantadilla.lemis.com>; from grog@lemis.com on Fri, Oct 13, 2000 at 10:39:14AM +0930 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Oct 13, 2000 at 10:39:14AM +0930, Greg Lehey wrote: > On Thursday, 12 October 2000 at 15:37:29 -0700, Jason Evans wrote: > > For lockmgr mutex protection, use an array of mutexes that are allocated > > and initialized during boot. This avoids bloating sizeof(struct lock). > > As a side effect, it is no longer necessary to enforce the assumtion that > > lockinit()/lockdestroy() calls are paired, so the LK_VALID flag has been > > removed. > > I'm just doing the slides for the Con, and going through the sources I > note that we have sprouted a plethora of mutexes over the last month. > How are we keeping track of them? How does somebody who wants to add > a new mutex know where the mines are? I'm not sure I understand what you're getting at, if you're using my commit as an example. The lockmgr mutexes are leaf locks, so for most intents and purposes (i.e. unless someone is mucking with the lockmgr code itself), no one needs to know that they exist. What issues are you implying exist for someone who wants to add a new mutex to the system, that can be solved by cataloging all mutex instances? I would agree if you were to state that care must be taken to follow certain rules in order to avoid bad mutex interactions, but I'm missing why you think a mutex catalogue is a necessary thing. On a related note (and perhaps the real answer you're looking for), John Baldwin and Chuck Paterson came up with an initial set of rules for kernel synchronization (subject to change), which is available at: http://people.freebsd.org/~jasone/smp/smp_synch_rules.html While I'm at it, here's a reminder that the SMP project status is being tracked at: http://people.freebsd.org/~jasone/smp/ Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Oct 12 19:19:56 2000 Delivered-To: freebsd-smp@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 564D837B502 for ; Thu, 12 Oct 2000 19:19:51 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e9D2JhZ02809; Fri, 13 Oct 2000 11:49:43 +0930 (CST) (envelope-from grog) Date: Fri, 13 Oct 2000 11:49:42 +0930 From: Greg Lehey To: Jason Evans Cc: FreeBSD SMP list Subject: Re: New mutexes Message-ID: <20001013114942.E2593@wantadilla.lemis.com> References: <200010122237.PAA12428@freefall.freebsd.org> <20001013103913.B2467@wantadilla.lemis.com> <20001012190443.G11949@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001012190443.G11949@canonware.com>; from jasone@canonware.com on Thu, Oct 12, 2000 at 07:04:43PM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thursday, 12 October 2000 at 19:04:43 -0700, Jason Evans wrote: > On Fri, Oct 13, 2000 at 10:39:14AM +0930, Greg Lehey wrote: >> On Thursday, 12 October 2000 at 15:37:29 -0700, Jason Evans wrote: >>> For lockmgr mutex protection, use an array of mutexes that are allocated >>> and initialized during boot. This avoids bloating sizeof(struct lock). >>> As a side effect, it is no longer necessary to enforce the assumtion that >>> lockinit()/lockdestroy() calls are paired, so the LK_VALID flag has been >>> removed. >> >> I'm just doing the slides for the Con, and going through the sources I >> note that we have sprouted a plethora of mutexes over the last month. >> How are we keeping track of them? How does somebody who wants to add >> a new mutex know where the mines are? > > I'm not sure I understand what you're getting at, if you're using my commit > as an example. No, your commit just reminded me of the issue :-) > The lockmgr mutexes are leaf locks, so for most intents and purposes > (i.e. unless someone is mucking with the lockmgr code itself), no > one needs to know that they exist. What issues are you implying > exist for someone who wants to add a new mutex to the system, that > can be solved by cataloging all mutex instances? Well, deadlocks for one. > I would agree if you were to state that care must be taken to follow > certain rules in order to avoid bad mutex interactions, but I'm > missing why you think a mutex catalogue is a necessary thing. > > On a related note (and perhaps the real answer you're looking for), John > Baldwin and Chuck Paterson came up with an initial set of rules for kernel > synchronization (subject to change), which is available at: > > http://people.freebsd.org/~jasone/smp/smp_synch_rules.html Yes, that's good stuff. That's the sort of thing I'm looking for, but I hadn't heard of it before. I suppose we can talk more about this next week. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Oct 12 19:44:28 2000 Delivered-To: freebsd-smp@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 580AC37B502; Thu, 12 Oct 2000 19:44:25 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id TAA25383; Thu, 12 Oct 2000 19:44:48 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAT9aaFX; Thu Oct 12 19:44:38 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA03795; Thu, 12 Oct 2000 19:44:12 -0700 (MST) From: Terry Lambert Message-Id: <200010130244.TAA03795@usr05.primenet.com> Subject: Re: New mutexes (was: cvs commit: src/sys/conf param.c src/sys/kern kern_lock.c src/sys/sys kernel.h lock.h src/sys/vm vm_map.h) To: grog@lemis.com (Greg Lehey) Date: Fri, 13 Oct 2000 02:44:12 +0000 (GMT) Cc: jasone@FreeBSD.ORG (Jason Evans), FreeBSD-smp@FreeBSD.ORG (FreeBSD SMP list) In-Reply-To: <20001013103913.B2467@wantadilla.lemis.com> from "Greg Lehey" at Oct 13, 2000 10:39:14 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-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm just doing the slides for the Con, and going through the sources I > note that we have sprouted a plethora of mutexes over the last month. > How are we keeping track of them? How does somebody who wants to add > a new mutex know where the mines are? The mines are anywhere more than 1 mutex is held, anywhere that a mutex is held with a recursion count greater than 0, and anywhere code that can sleep holds a mutex. There are also "stealth" mines in any function that holds a mutex over a break, goto, loop control structure, or conditional statement that can return (e.g. any function that is not single entry, single exit). There are implied mines ("this side towards enemy" screwup potential) everywhere there is data manipulation of anything but stack data, where a mutex is _not_ held. There are "bouncing betties" (mines which blow up later, killing the rest of the squad, when the point man screws up) everywhere an interrupt or trap handling function doesn't hold a mutex over an implied mine. These have the benefit of leaving the point man alive, so that when he's reassigned, he can kill the next squad following him, too. --- As to tracking them: use a mutex. 8-). Acquire the mutex that allows you to add a mutex Add the new mutex Release the mutex adding mutex (Requires you to document your addition) You might recognize this as multiple reader/single writer locks on the source tree, with overall change comments, circa 1994, as in: Acquire: co -l changemutex Add new mutex: cvs ci Release/document: ci -u changemutex Back in 1992/1993, we had shell scripts that wrapped CVS and added a "cvs lock" and "cvs unlock" (and "cvs unlock -f") "subcommands" to support this (this was at Novell). 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-smp" in the body of the message From owner-freebsd-smp Fri Oct 13 6:25:48 2000 Delivered-To: freebsd-smp@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id 7C1C637B503; Fri, 13 Oct 2000 06:25:46 -0700 (PDT) From: "Jonathan M. Bresler" To: tlambert@primenet.com Cc: grog@lemis.com, jasone@FreeBSD.ORG, FreeBSD-smp@FreeBSD.ORG In-reply-to: <200010130244.TAA03795@usr05.primenet.com> (message from Terry Lambert on Fri, 13 Oct 2000 02:44:12 +0000 (GMT)) Subject: Re: New mutexes (was: cvs commit: src/sys/conf param.c src/sys/kern kern_lock.c src/sys/sys kernel.h lock.h src/sys/vm vm_map.h) Message-Id: <20001013132546.7C1C637B503@hub.freebsd.org> Date: Fri, 13 Oct 2000 06:25:46 -0700 (PDT) Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > There are "bouncing betties" (mines which blow up later, killing bouncing betties are mines that contain two explosive devices. the first loft the mine several feet into the air. the second is the main explosive. > the rest of the squad, when the point man screws up) everywhere these are delayed action mines. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Oct 13 12:41:13 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id BD9D037B66F; Fri, 13 Oct 2000 12:41:10 -0700 (PDT) Received: from laptop.baldwin.cx (ether.osd.bsdi.com [204.216.28.196]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9DJe9520192; Fri, 13 Oct 2000 12:40:56 -0700 (PDT) (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: <200010130244.TAA03795@usr05.primenet.com> Date: Fri, 13 Oct 2000 12:40:28 -0700 (PDT) From: John Baldwin To: Terry Lambert Subject: Re: New mutexes (was: cvs commit: src/sys/conf param.c src/sys/k Cc: (FreeBSD SMP list) Cc: (FreeBSD SMP list) , (Jason Evans) , (Greg Lehey) Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13-Oct-00 Terry Lambert wrote: >> I'm just doing the slides for the Con, and going through the sources I >> note that we have sprouted a plethora of mutexes over the last month. >> How are we keeping track of them? How does somebody who wants to add >> a new mutex know where the mines are? > > The mines are anywhere more than 1 mutex is held, anywhere that > a mutex is held with a recursion count greater than 0, and > anywhere code that can sleep holds a mutex. We are working on a list of rules atm, the current list can be found on the SMP website (http://www.FreeBSD.org/~jasone/smp/). > --- > > As to tracking them: use a mutex. 8-). > > Acquire the mutex that allows you to add a mutex > Add the new mutex > Release the mutex adding mutex (Requires you to document your addition) We already do this. Please, at least look at the code we are using. -- 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-smp" in the body of the message From owner-freebsd-smp Fri Oct 13 12:41:21 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id E236737B66D for ; Fri, 13 Oct 2000 12:41:19 -0700 (PDT) Received: from laptop.baldwin.cx (ether.osd.bsdi.com [204.216.28.196]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9DJew520199; Fri, 13 Oct 2000 12:40:58 -0700 (PDT) (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: <20001013114942.E2593@wantadilla.lemis.com> Date: Fri, 13 Oct 2000 12:41:16 -0700 (PDT) From: John Baldwin To: Greg Lehey Subject: Re: New mutexes Cc: FreeBSD SMP list Cc: FreeBSD SMP list , Jason Evans Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13-Oct-00 Greg Lehey wrote: >> On a related note (and perhaps the real answer you're looking for), John >> Baldwin and Chuck Paterson came up with an initial set of rules for kernel >> synchronization (subject to change), which is available at: >> >> http://people.freebsd.org/~jasone/smp/smp_synch_rules.html > > Yes, that's good stuff. That's the sort of thing I'm looking for, but > I hadn't heard of it before. It's only existed for all of 3-5 days. :) > I suppose we can talk more about this next week. Yes, most definitely. > Greg -- 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-smp" in the body of the message From owner-freebsd-smp Sat Oct 14 18:53:29 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc1.ne.home.com (ha1.rdc1.ne.home.com [24.2.4.66]) by hub.freebsd.org (Postfix) with ESMTP id 0F7E237B502 for ; Sat, 14 Oct 2000 18:53:27 -0700 (PDT) Received: from cx443070b ([24.0.36.170]) by mail.rdc1.ne.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001015015325.KCKN1658.mail.rdc1.ne.home.com@cx443070b> for ; Sat, 14 Oct 2000 18:53:25 -0700 Message-ID: <01e501c0364c$3a89d5e0$aa240018@vista1.sdca.home.com> From: "Jeremiah Gowdy" To: References: <200010061652.KAA14529@berserker.bsdi.com> Subject: MP Generic Kernel Date: Sat, 14 Oct 2000 19:04:18 -0700 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm wondering if we can't include a generic MP kernel in the FreeBSD releases. Basically, on a fresh install of a dual cpu box, we find that we have to compile the kernel and/or world on a single cpu the first time through. It seems a simple enough matter to include kernel.smp or something to that effect in the standard ISO/CD release so that a knowledgable FreeBSD user/admin could interrupt the boot process, and boot kernel.smp. Perhaps even the disk version could include a choice of a standard boot floppy or an SMP boot floppy. It's not as though releases are every other day, so it doesn't seem that this would be all that great of a chore, and it would allow those of us who admin alot of SMP boxes to save us a single cpu buildworld. The only reason I suggest this is that it is my understanding that with the 4.1/4.1.1 releases one must buildworld before compiling kernel. On the older systems, one would simply compile an SMP kernel and reboot and be up and running dual cpus for the buildworld. Anyhow, just a suggestion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message