From owner-freebsd-current Tue Feb 10 19:45:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA27435 for current-outgoing; Tue, 10 Feb 1998 19:45:49 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA27429 for ; Tue, 10 Feb 1998 19:45:45 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id UAA26430; Tue, 10 Feb 1998 20:45:39 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd026412; Tue Feb 10 20:45:34 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id UAA02149; Tue, 10 Feb 1998 20:45:31 -0700 (MST) From: Terry Lambert Message-Id: <199802110345.UAA02149@usr04.primenet.com> Subject: Re: Minor test from somebody with SMP needed To: eivind@yes.no (Eivind Eklund) Date: Wed, 11 Feb 1998 03:45:31 +0000 (GMT) Cc: smp@csn.net, eivind@yes.no, current@FreeBSD.ORG In-Reply-To: <19980210182124.35246@follo.net> from "Eivind Eklund" at Feb 10, 98 06:21:24 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > These routines can't work with SMP as they substitute for real locks > > and an SMP machine would soon go down in flames if it depended on them. > > They are a debug mechanism for a single CPU system, and predate the > > FreeBSD developmnent effort. > > OK, what is the right fix, then? I can see three obvious 'fixes' for > the time being: > > 1. Make SIMPLELOCK_DEBUG a no-op if NCPUS > 1 > > 2. Rip out the SIMPLELOCK_DEBUG code (if it is no longer usable, and > not likely to become usable) > > 3. Do the below change (basically an error if compiling anything other > than LINT with SIMPLELOCK_DEBUG and SMP) They need to be real locks. The reason they need to be real locks is that if kernel preemption is to be allowed in kernel threading, then there may be a case they need to lock against. Topologically, kernel preemption on a single CPU is equivalent to the problem of multiple CPU's being in the kernel. You should probably get with John Dyson on this; he's the most vocal advocate of kernel threads. 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 current" in the body of the message