Date: Sun, 17 Feb 2002 16:24:04 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.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: <3C7049A4.15412853@mindspring.com> References: <5405.1013975811@critter.freebsd.dk> <200202172011.g1HKBsv88526@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?3C7049A4.15412853>