Date: Tue, 29 Jun 1999 13:03:06 -0500 (EST) From: Alfred Perlstein <bright@rush.net> To: Kevin Van maren <vanmaren@cs.utah.edu> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: high-efficiency SMP locks - submission for review Message-ID: <Pine.BSF.3.96.990629125049.14320X-100000@cygnus.rush.net> In-Reply-To: <199906291705.LAA20627@zane.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Jun 1999, Kevin Van maren wrote:
> Alfred Perlstein said:
> > getpid would read the contents of a page mapped into the process'
> > address space, ie, the kernel sharing info with processes through
> > shared mappings?
>
> Because the cost of setting up the mappings, and the wasted page
> of memory, greatly exceeds the cost of a system call that is used
> at most (usually) once per process. The only time getpid() is called
> several times is during (bad) synthetic benchmarks. Having libc cache
> the value would be a more viable solution; it would have to trap fork()
> calls, however, to invalidate the stored pid.
Well there are other things you could accomplish by this, since
there are usermode test/set you can check for and manipulate
signal stuff. The amount of help this would lend to user threads
could really only be gauged by the authors of it, but I guess it
would really help context switching... Getpid is a bad example
and the idea should be thought out to see if it is worth it, however
I just wanted to bring it up in case someone thought it would provide
a super fast API to certain kernel structures.
Also the mappings could be lazy, basically only calls to functions that
use the shared API would map them in on first call.. Just an idea,
implementing it solely for getpid() would be dumb, but maybe
there are cases where it's a big win?
> Compiling and storing 8 kernels for the loader to choose from sounds
> like a bad idea as well; it may be practical for CD-ROM installation,
> although I think it is more likely the user will select the right one.
That's what I meant, for the first install, also the ability to see
if the motherboard is smp to automagically boot an smp kernel so some
benchmark weenie can't "accidentally" test against an UP kernel on
a SMP system... It would also help with installs so that people
doing installs that are happy with GENERIC would still get SMP.
There is no need to provide a kernel for each i386 step, just the
following cases:
386 (slow copyin/copyout), 486-pII(optimized copyin/out),
SMP (smp enabled and pentium optimizations enabled)
For some reason I think it would be just kinda cool if the loader
checked the /kernel for some sort of signature (it's elf) if not
it attempts to load it as a boot script to select the kernel
to boot via variables exported by the loader.
-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-smp" 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.990629125049.14320X-100000>