Date: Thu, 24 Jun 1999 21:26:21 -0400 (EDT) From: "Brian F. Feldman" <green@unixhelp.org> To: Alfred Perlstein <bright@rush.net> Cc: Karl Denninger <karl@Denninger.Net>, hackers@FreeBSD.ORG Subject: Re: Microsoft performance (was: ...) Message-ID: <Pine.BSF.4.10.9906242120590.16674-100000@janus.syracuse.net> In-Reply-To: <Pine.BSF.3.96.990624195759.14320F-100000@cygnus.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Jun 1999, Alfred Perlstein wrote:
> 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.
I meant something like an extensible set of mutex "groups", like our
kernel malloc uses. New mutex types would be added. Instead of per-
function mutexes, a single mutex "type" could be used for multiple functions
that are the same in usage of sensitive resources. Just an idea...
>
> 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
>
>
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
green@FreeBSD.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
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.4.10.9906242120590.16674-100000>