Date: Thu, 24 Jun 1999 23:49:39 -0500 (EST) From: Alfred Perlstein <bright@rush.net> To: Kris Kennaway <kkennawa@physics.adelaide.edu.au> Cc: hackers@FreeBSD.ORG Subject: Re: Microsoft performance (was: ...) Message-ID: <Pine.BSF.3.96.990624234242.14320G-100000@cygnus.rush.net> In-Reply-To: <Pine.OSF.4.10.9906251103580.22202-100000@bragg>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990624234242.14320G-100000>