From owner-freebsd-arch@FreeBSD.ORG Tue Aug 16 12:59:31 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 CEF1E16A41F; Tue, 16 Aug 2005 12:59:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34F6C43D55; Tue, 16 Aug 2005 12:59:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [172.20.101.145] ([12.167.156.2]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j7GDAL8Q045243; Tue, 16 Aug 2005 07:10:21 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4301E303.9060101@samsco.org> Date: Tue, 16 Aug 2005 06:58:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <42F9ECF2.8080809@freebsd.org> <200508101638.27087.jhb@FreeBSD.org> <42FA6E0E.4070205@samsco.org> <200508111121.46546.jhb@FreeBSD.org> <20050816051231.D66550@xorpc.icir.org> In-Reply-To: <20050816051231.D66550@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org 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:59:32 -0000 Luigi Rizzo wrote: > 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 > You're saying that you would like a system where a thread that wants a lock can ask another thread that has the lock to temporarily give it up and go to sleep? Scott > 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"