Date: Fri, 25 Aug 2000 11:26:03 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Alfred Perlstein <bright@wintelcom.net> Cc: Robert Watson <rwatson@FreeBSD.ORG>, Jonas Bulow <jonas.bulow@servicefactory.se>, hackers@FreeBSD.ORG Subject: Re: freebsd and non-preemtive threads Message-ID: <200008251526.e7PFQ3631621@whizzo.transsys.com> In-Reply-To: Your message of "Mon, 21 Aug 2000 18:13:16 PDT." <20000821181316.J4854@fw.wintelcom.net> References: <3997C2C5.83AFE056@servicefactory.se> <Pine.NEB.3.96L.1000821200949.89810I-100000@fledge.watson.org> <20000821181316.J4854@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> * Robert Watson <rwatson@FreeBSD.ORG> [000821 18:01] wrote: > > > > For reference, my recollection is that peemption-aware userland thread > > libraries tend to make alot of timer syscalls, losing some of the > > advantage of being a userland thread library (low context switch cost, few > > transistions between user/kerneland). The AFS LWP code included a > > fasttime() mechanism that took advantage of the ability to mmap kernel > > memory under SunOS, allowing direct access to the timer variable in > > kernel, without a context switch. I do not believe that native ports to > > Linux/FreeBSD/et al have retained this capability, especially given its > > requirements for privilege. However, it would be easy to imagine a kernel > > module exporting a /dev/time, which had the singular ability of allowing > > the mmaping of a page containing only the kernel's timer variables, > > permitting syscall-free precise time access from userland using atomic > > memory access calls. > > I think phk and I discussed this about a year ago, our idea was to > automatically map the segment in for each process (also allowing > things like getpid and such to be accessable). > > It would be nice to see happen either way (mmap'able /dev/time or > automatically) If it's a uni-processor machine, could you use the cycle counter register? I wrote a driver under FreeBSD 3.0 for the Datum bc635PCI which allowed a process to mmap() the device registers of this board. With two memory references, you'd get a timestamp with 100ns resolution, which was handy for a bunch of tasks. I don't know that a /dev/time would give you sufficient resolution, as convienient memory-based stuff would only be updated everytime hardclock() ran, at HZ times per second. The gettimeofday(), etc., routines do some other fiddling (like the TSC register, or reading other programmable timer devices). louie 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?200008251526.e7PFQ3631621>