From owner-freebsd-hackers Thu Jun 24 21:47:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 613E314E3E for ; Thu, 24 Jun 1999 21:47:34 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id AAA24626; Fri, 25 Jun 1999 00:49:41 -0400 (EDT) Date: Thu, 24 Jun 1999 23:49:39 -0500 (EST) From: Alfred Perlstein To: Kris Kennaway Cc: hackers@FreeBSD.ORG Subject: Re: Microsoft performance (was: ...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 25 Jun 1999, Kris Kennaway wrote: > On Thu, 24 Jun 1999, Alfred Perlstein wrote: > > > Pardon the niaveness of this idea, but things like per-CPU > > malloc areas and each CPU haveing a queue for CPUs if > > memory is free'd by a processor that down't "own" it. > > Things like someone signalling another processor if one of its > > free queues becomes full, or if a CPU finds its pool exhausted. > > This sounds a lot like local resource management in a distributed locking > system (the local lock manager obtains covering locks on a pool of resources > and can manage those locally, but can relinquish the locks to another lock > manager when requested if it is holding them but not actually using them). > > Concurrency theory interests me, but I don't have the resources (heh, heh) to > be useful at the moment. Theoretically you can simulate an SMP enviorment by removing the "run to completion" way that the kernel works, basically in UP while the kernel is working, it can't be interupted. By removing that restriction and at the same time putting up boundries on all syscalls to push that down you can pretty much simulate the effect of SMP. The farther you push the barriers down in the codepaths the better things get, with the eventual hope of removing them almost entirely. Right now most kernel utility functions would also need to grab the status of the lock and push it down then restore it apon return. This way malloc and friends can be considered "safe". btw, am I using the word "codepath" correctly? is it even a word? :) -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message