Date: Fri, 12 May 2006 19:02:20 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= <lists@wm-access.no> Cc: current@freebsd.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) Message-ID: <20060512090220.GB714@turion.vk2pj.dyndns.org> In-Reply-To: <4464414A.80100@wm-access.no> References: <20060506150622.C17611@fledge.watson.org> <20060509181302.GD3636@eucla.lemis.com> <20060509182330.GB92714@xor.obsecurity.org> <200605100726.28243.davidxu@freebsd.org> <44613469.2050000@freebsd.org> <4461522D.9060405@freebsd.org> <Pine.GSO.4.64.0605092346340.21472@sea.ntplx.net> <446165B5.7030006@freebsd.org> <20060510074547.GA700@turion.vk2pj.dyndns.org> <4464414A.80100@wm-access.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060512090220.GB714>