From owner-freebsd-performance@FreeBSD.ORG Wed May 10 10:31:52 2006 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0BED16A402; Wed, 10 May 2006 10:31:52 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A273043D46; Wed, 10 May 2006 10:31:52 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [137.122.74.158] (host158.thm10.resonet.uottawa.ca [137.122.74.158]) by elvis.mu.org (Postfix) with ESMTP id 452E41A4D89; Wed, 10 May 2006 03:31:52 -0700 (PDT) Message-ID: <4461C10B.7020703@FreeBSD.org> Date: Wed, 10 May 2006 12:31:39 +0200 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <20060506150622.C17611@fledge.watson.org> <200605090335.00451.hadara@bsd.ee> <20060509004203.GA55852@xor.obsecurity.org> <200605091818.12676.hadara@bsd.ee> <4460D2CA.5090808@elischer.org> <20060509183127.GD17515@retch.ugcs.caltech.edu> <4461A77F.5080508@FreeBSD.org> <20060510101119.GB700@turion.vk2pj.dyndns.org> In-Reply-To: <20060510101119.GB700@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, current@freebsd.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2006 10:31:53 -0000 Peter Jeremy wrote: > On Wed, 2006-May-10 10:42:39 +0200, Suleiman Souhlal wrote: > >>That's not enough. On some CPUs (like the current Opterons), the TSC >>slows down when the CPU executes a HLT instruction, so if you want good >>accuracy, you'll need to take that into account too. > > > The CPU can't be executing any instructions whilst it's halted. All > you need to do is update the base time/TSC count between when you exit > halt and when you return to userland. > > Since most sane code doesn't call gettimeofday() multiple times per > tick, one option might be to unmap the page when the base data becomes > invalid and update/remap the page when it is first accessed. > Another way would be to catch the first rdtsc call after a HLT, and reset the TSC to a good value. You can do this by making rdtsc usable only in ring0, which will make any userland rdtsc generate a general protection fault. You have to be careful, though, because on some Intel CPUs, you can only change the lower 32 bits of the TSC (the upper 32 bits get reset to 0 every time you write to the TSC). We actually implemented this at work, on Linux, to make sure that the TSCs between every processor is synchronized, and it appears to work pretty well. -- Suleiman