Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)

On Fri, 2006-May-12 10:03:22 +0200, Sten Daniel Srsdal wrote:
>How about making the scheduler insert the current time into something
>resembling in functionality of a cpu local variable (register? cache
>area?) whenever there is a context switch by the scheduler. Then
>whenever you need the current time the userland application would read
>it off this cpu local variable/holy area requiring no additional context
>switch.

Normally, context switches occur quite frequently (my mostly idle
laptop is reporting 550-650 context switches/second whilst I type
this) - probably more so than gettimeofday() calls.  Whilst this
approach saves a system call to read the time, you are probably paying
for lots more microtime() calls - which are not inexpensive on
FreeBSD.

That was the main reason for my suggestion that magic page (your "cpu
local variable/holy area") be left unmapped with the microtime() call
(and other per-timeslice initialisation) occurring on the first call
to gettimeofday() in that timeslice.  (Much like the npx is handled).

>Or do the currently running (on that cpu) userland application require
>the ability to read the current time more often than once per "time
>slot"? Do i make sense?

A timeslice can last for a long time (I think it's up to about 4 clock
ticks).  You get back to the tradeoff of cheap vs accurate.

-- 
Peter Jeremy