From owner-freebsd-current@FreeBSD.ORG Fri May 12 09:02:26 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8F7416A409 for ; Fri, 12 May 2006 09:02:26 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BB6443D46 for ; Fri, 12 May 2006 09:02:23 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail06.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k4C92LVY011120 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 12 May 2006 19:02:21 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k4C92KaQ001231; Fri, 12 May 2006 19:02:20 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k4C92KSR001230; Fri, 12 May 2006 19:02:20 +1000 (EST) (envelope-from peter) Date: Fri, 12 May 2006 19:02:20 +1000 From: Peter Jeremy To: Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= Message-ID: <20060512090220.GB714@turion.vk2pj.dyndns.org> Mail-Followup-To: Peter Jeremy , Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= , current@freebsd.org 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> <446165B5.7030006@freebsd.org> <20060510074547.GA700@turion.vk2pj.dyndns.org> <4464414A.80100@wm-access.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4464414A.80100@wm-access.no> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2006 09:02:35 -0000 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