From owner-freebsd-hackers Mon Nov 10 12:31:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA26182 for hackers-outgoing; Mon, 10 Nov 1997 12:31:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from srv.net (snake.srv.net [199.104.81.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA26176 for ; Mon, 10 Nov 1997 12:31:49 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-20.ida.net [208.141.171.125]) by srv.net (8.8.7/8.8.5) with SMTP id NAA13490 for ; Mon, 10 Nov 1997 13:31:12 -0700 (MST) Date: Mon, 10 Nov 1997 13:30:38 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: hackers@freebsd.org Subject: Reading kernel memory Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I had earlier asked some questions about reducing the overhead in a gettimeofday() system call. One suggestion was to somehow map kernel memory into user space and read the system time variable. I have just tried doing this via the kvm_read() function, and it takes about 200 microseconds on a 386 to do this. In comparison, gettimeofday() takes only about 60 microseconds on the same machine. So if one really wants to map a kernel variable to user space, I am guessing something more sophisticated than the kvm routines are needed. [Note: originally I became interested in this as a way to speed up libalias a little bit, but this is really irrelevant now. I am more interested in understanding some of the underlying principles here. Please forgive my lack of practicality.] Wandering through the kernel source code, I have also discovered that gettimeofday() actaully invokes a microtime() call which actually tries to determine the time by reading a timer and using it to refine the kernel time variable. I was quite impressed by this, as previous experience with Linux indicates they just use a time variable updated every kernel quantum. The FreeBSD kernel treats the subject of time quite seriously. Charles Mott