From owner-freebsd-stable Fri Aug 9 10:17:44 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3EA637B401 for ; Fri, 9 Aug 2002 10:17:41 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-156-170.client.attbi.com [12.233.156.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D83AF43E86 for ; Fri, 9 Aug 2002 10:17:39 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.3/8.12.3) with ESMTP id g79HHqUN000415; Fri, 9 Aug 2002 10:17:53 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.3/8.12.3/Submit) id g79HHhon000414; Fri, 9 Aug 2002 10:17:43 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Fri, 9 Aug 2002 10:17:43 -0700 From: David Schultz To: kpieckiel@smartrafficenter.org Cc: Bosko Milekic , Mario Pranjic , freebsd-stable@FreeBSD.ORG Subject: Re: SMP kernel: FreeBSD vs. Linux 2.4.x Message-ID: <20020809171743.GB290@HAL9000.homeunix.com> Mail-Followup-To: kpieckiel@smartrafficenter.org, Bosko Milekic , Mario Pranjic , freebsd-stable@FreeBSD.ORG References: <20020809091008.A87124@unixdaemons.com> <20020809164411.GC78503@pacer.dmz.smartrafficenter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020809164411.GC78503@pacer.dmz.smartrafficenter.org> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Kevin A. Pieckiel : > A few questions on this issue. First, what was the reasoning behind making > the whole kernel a critical code segment? I can't think of any reason > kernel developers would have to design the kernel this way, shy of sheer > laziness or such profound architectural changes being necessary to impliment > it otherwise. In either case, I see both mindsets leading to the "we'll fix > it later" path early in kernel development, and I'm sure the developers knew > full well it would be harder to fix later rather than sooner. Of course, > not being a kernel developer, I couldn't even begin to fathom all that is > involved in such changes, so I truely am speaking from ignorance on the > subject. Any enlightening thoughts to help me understand this bit? Unix was originally designed for uniprocessor systems. Consequently, some assumptions were made that are reasonable and result in lower locking overhead for uniprocessors, but that aren't valid for multiprocessors. http://www.lemis.com/~grog/SMPng/USENIX/ > Second, what are KSEs? cf. Scheduler Activations: http://citeseer.nj.nec.com/anderson92scheduler.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message