From owner-freebsd-arch@FreeBSD.ORG Tue Aug 16 12:12:53 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4E0A16A41F; Tue, 16 Aug 2005 12:12:53 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BAA343D46; Tue, 16 Aug 2005 12:12:53 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j7GCCYeR066933; Tue, 16 Aug 2005 05:12:34 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j7GCCVpr066932; Tue, 16 Aug 2005 05:12:31 -0700 (PDT) (envelope-from rizzo) Date: Tue, 16 Aug 2005 05:12:31 -0700 From: Luigi Rizzo To: John Baldwin Message-ID: <20050816051231.D66550@xorpc.icir.org> References: <42F9ECF2.8080809@freebsd.org> <200508101638.27087.jhb@FreeBSD.org> <42FA6E0E.4070205@samsco.org> <200508111121.46546.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200508111121.46546.jhb@FreeBSD.org>; from jhb@freebsd.org on Thu, Aug 11, 2005 at 11:21:45AM -0400 Cc: frank@exit.com, Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: Special schedulers, one CPU only kernel, one only userland X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2005 12:12:53 -0000 reading this thread, and at times looking at some of the kernel code, with plenty of places where you have to drop a lock that you already have, do some small thing and then reacquire the lock itself, makes me wonder if we don't need a better mechanism/abtraction for this kind of programming. In a way, this seems similar to the handling of interrupts: if we want a thread to be interrupted we don't check for interrupts (and save and restore state) explicitly at every instruction, but rely on the processor doing the right thing for us. I am sorry i cannot formulate the analogy in a clearer way (if i could i would probably have a design to address this problem :( ) cheers luigi On Thu, Aug 11, 2005 at 11:21:45AM -0400, John Baldwin wrote: > On Wednesday 10 August 2005 05:13 pm, Scott Long wrote: > > John Baldwin wrote: > > > On Wednesday 10 August 2005 04:10 pm, Frank Mayhar wrote: > > >>On Wed, 2005-08-10 at 09:11 -0400, John Baldwin wrote: > > >>>I think this is the model that BSD/OS employed > > >>>for SMP in its 4.x series before they did their version of SMPng. > > >> > > >>I didn't grunge around in the scheduler (much), but as far as I'm aware > > >>BSD/OS 4.x used the Big Giant Lock mechanism just as FreeBSD did, and > > >>for the same reason. > > > > > > I believe that at some point during the 4.x series they added a scheduler > > > lock that covered just enough to allow threads that weren't asleep in the > > > kernel to be switched to without require the big giant lock and that it > > > was a pretty decent performance win over the earlier single BGL ala > > > FreeBSD 4.x. > > > > So when a syscall is made on an AP, does it get serviced on the same AP > > (assuming that the lock is available and no sleeping is needed), or does > > it get serviced my the BSP? Where kernel threads explicitely pinned to > > the BSP? Was the APIC explicitely programmed to deliver only to the > > BSP? > > I think the AP would block on the BGL in the stuff BSD/OS did, but Schimmel > points out that that can be non-optimal (SMP in 4.x was basically about the > worst possible idea according to Schimmel). A better implementation of > master/slave is for all syscalls, traps, and interrupts to run only on the > BSP and have the APs just run in userland. I.e. they could take over a > thread that had made it to userret (when you get to userret, you would mark > the thread as a user thread somwhow) and when a thread running on an AP > wanted to enter the kernel (syscall or trap), it would have to stick the > thread on the runqueue for the BSP and go look for another user thread. > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"