From owner-freebsd-hackers Thu Jun 24 18:12:13 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 7214C15179 for ; Thu, 24 Jun 1999 18:12:01 -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 VAA14602; Thu, 24 Jun 1999 21:14:20 -0400 (EDT) Date: Thu, 24 Jun 1999 20:14:19 -0500 (EST) From: Alfred Perlstein To: "Brian F. Feldman" Cc: Karl Denninger , 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 Thu, 24 Jun 1999, Brian F. Feldman wrote: > On Thu, 24 Jun 1999, Alfred Perlstein wrote: > > > On Thu, 24 Jun 1999, Karl Denninger wrote: > > > > A simple start would be to explicitly put a macro or call in each > > syscall to push down the lock. That way people can move that > > macro farther and farther down in the syscall code path, hopefully > > removing it entirely in some cases. I think having the call at > > the beginning of each syscall would motivate people into doing that > > sort of work. > > > > "Hey, y'know getppid() is safe, i'll just take the lock out." > > "this function xxx() is safe until this point I can process a lot > > before actually needing this lock..." > > "y'know I just have a structure that's not accessable to any other calls > > that i'm going to fill in, i'll just lift the lock right here" > > "if I just do this something here, I really am re-entrant and safe.." > > > > Providing a simple api for spinlocks and mutexes would be very nice. > > > > Something along the lines of how spl()s work? And mutex allocation like what > we do with malloc types, maybe? I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. Also, some really interesting things could be done via per-CPU resource pools to lower the amount of contention on objects. 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. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message