Date: Fri, 12 May 2006 10:03:22 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= <lists@wm-access.no> To: Peter Jeremy <peter@vk2pj.dyndns.org>, David Xu <davidxu@freebsd.org>, Daniel Eischen <deischen@freebsd.org>, current@freebsd.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) Message-ID: <4464414A.80100@wm-access.no> In-Reply-To: <20060510074547.GA700@turion.vk2pj.dyndns.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> <Pine.GSO.4.64.0605092346340.21472@sea.ntplx.net> <446165B5.7030006@freebsd.org> <20060510074547.GA700@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > SunOS 4 (not sure about SunOS 5) exports a per-CPU page that > includes a high-resolution timer amongst other things. >=20 > On Wed, 10 May 2006, David Xu wrote: >> One of the problems to implement it is that atomic operations, >> if there are multiple integer needs to be updated by kernel, >> userland maybe gets an inconsistent result, the way to avoid the >> problem is using two generation numbers. >=20 > A lot of the need for atomic operations goes away if the page (or > whatever) refers to the current CPU - the page is either being updated > by the current CPU in kernel mode or read by the current CPU in > userland. The page won't be updated/accessed by other CPUs. You > still need to update the base time and TSC (or whatever) count in a > way that looks atomic to userland but I suspect the kernel could > achieve this by twiddling the code transparently to userland (eg there > are two copies of the base/count and the kernel flips a pointer > between then). >=20 > On Wed, 2006-May-10 12:01:57 +0800, David Xu wrote: >> Daniel Eischen wrote: >>> Can you not make a simple pseudo device driver and mmap the page? >>> >> mmap is fine if you don't care binary compatible, exporting a kernel >> page which can be executed by userland is more flexible, kernel can >> change it freely without having to change libc. >=20 > These aren't mutually exclusive - .so's are mmap'd. All libc needs > to do is mmap a page from a pseudo device and execute a function in > it. Either the function could be at a magic address or the pseudo > device could simulate a shared object so you just dlopen() the device. >=20 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. 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? *ducks for cover* --=20 Sten Daniel S=F8rsdal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4464414A.80100>