Date: Sun, 17 Feb 2002 16:30:30 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Julian Elischer <julian@elischer.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday()and copyout(). Is copyout() MPSAFE on non-i386 archs? ) Message-ID: <200202180030.g1I0UU309210@apollo.backplane.com> References: <5405.1013975811@critter.freebsd.dk> <200202172011.g1HKBsv88526@apollo.backplane.com> <3C7049A4.15412853@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm just going to point something out here, and that is my proposed
system call fully supports the kernel saying, in effect, 'I don't want
you accessing this particular parameter from shared memory, use the
old way of doing it'.
For the vast majority of processes in a system this is a perfectly
reasonable response. The shared memory feature would only need to be
enabled for those few processes, like web servers, databases, and
big threaded programs that really need it.
So we can afford to waste some memory for the few processes that actually
need the feature as long as we don't waste any for the processes that
don't.
-Matt
Matthew Dillon
<dillon@backplane.com>
:Matthew Dillon wrote:
:> :Peter and I actually had a sligthly different idea:
:
:[ ... ]
:
:> This would make time-of-day updates rather costly.
:
:I'm pretty darn sure that Poul was referring to the
:getpid section of the conversation, and not to a
:gettimeofday specifically.
:
:> Frankly, there isn't much point mapping the pid, uid, etc... those
:> calls are not in the critical path. The signal mask would be useful.
:> But, again, I think it must be the kernel that does the mapping. It
:> is far too dangerous otherwise IMHO.
:
:See other post; it's a reflection out.
:
:The signal mask would fall into the same area as
:"current active user space thread", where writing it
:from user space would not be a bad thing.
:
:This gives us another 8k per process, and another 4k
:of global (if you want to throw gettimeofday into the
:mix).
:
:I guess the question is whether Poul's reflection
:suggestion for things that would normally be read-only
:from user space and add 4k with the simple expedient
:approach I siggested would be worth it.
:
:IMO, it probably would: changing gid our uid is not a
:common operation, and requires a system call anyway;
:an extra copyout isn't terrible overhead. There _is_
:a question of whether or not the overhead of doing a
:dual mapping is too expensive in terms of KVA space
:mapping (you would need two: one for read-only, and
:another for read-write in my approach).
:
:For process writable values, I think a page makes more
:sense, but the number of these is pretty small; of them,
:the signal mask would show incredible overall value if
:it existed in 4.x right now, particularly for libc_r.
:
:However, there is much less value in 5.x, I think, for
:this. The libc_r wrappers that manipulate the signal
:mask go away with the KSE code.
:
:In addition, we could probably get rid of the problem
:in libc_r, even in 4.x, by thinking about how to solve
:it correctly.
:
:It seems to me that we could unmask all signals, and set
:up a multiplex signal handler for all of them, in any
:threaded program, and apply the mask and do the dispatch
:from the multiplex handler, instead. In other words,
:turn all the signal functions visible to programs in a
:threaded context into user space calls, which would get
:rid of all those extra system calls.
:
:-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202180030.g1I0UU309210>