From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 15 19:13:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE39E603; Mon, 15 Apr 2013 19:13:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 04E35153D; Mon, 15 Apr 2013 19:13:35 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id k11so2433517eaj.32 for ; Mon, 15 Apr 2013 12:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dL9CFkwr3uaohHKnHkOWW2VUUtAo0Mt/3ByA90QWg5A=; b=UUIAVJT6Skg4Lcx3ZeTkzaaKLDoXvPDz9cfCD0px8LrHCxTTkB4YbHr6Wjv6ZnxWaz BsV6TsNHyZtT2vwlbxUZfxxm4TBpmF4M7KoDZma9qm1z8TYD/7yqmARMrwJm66AM5Dg/ /DLTK+0Pe1JNInQXUSj7xNlYhhS29LXvqDKdQgl8P16xcXlZfRf0EqlfhAIyBPMTIFOJ 3YMVauUHtyGLu/m+qv1ufz/r0xROkjtKspgWfmoFWb4CPaxpyslPD+W776r7vc7U6rh7 U1Pm6XZp3NB8p6xxCyT5awByXMQ6xtvYZ70MY+Z/k6VeG39ZxcoC6eR5S9TiAVcZWkpq r8oA== X-Received: by 10.14.149.141 with SMTP id x13mr32974188eej.31.1366053214378; Mon, 15 Apr 2013 12:13:34 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id u44sm28373499eel.7.2013.04.15.12.13.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 12:13:33 -0700 (PDT) Sender: Alexander Motin Message-ID: <516C515A.9090602@FreeBSD.org> Date: Mon, 15 Apr 2013 22:13:30 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: devstat overhead VS precision References: <51692C95.3010901@FreeBSD.org> <20130415184203.GA1839@garage.freebsd.pl> In-Reply-To: <20130415184203.GA1839@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:13:36 -0000 On 15.04.2013 21:42, Pawel Jakub Dawidek wrote: > On Sat, Apr 13, 2013 at 12:59:49PM +0300, Alexander Motin wrote: >> Hi. >> >> It is long known that collecting disk and GEOM statistics may cause >> significant processing overhead under high IOPS. On my recent high-IOPS >> benchmarks performance difference was reaching three times! Last time >> situation improved a lot by more active use of TSC, but there are still >> many systems where TSCs are not synchronized. I propose to switch that >> statistics from using binuptime() to getbinuptime() to solve the problem >> globally. >> >> From one side getbinuptime() resolution is limited by 1ms, but since >> time is usually averaged over the many I/Os, additional sub-millisecond >> precision will come from sampling. Since most of tools now show request >> processing times up to 0.1ms, that precision should be sufficient. I >> believe real disk performance is more important that n-th digit in some >> statistics. >> >> The following patch does the change and makes disk performance >> irrelevant to the timecounter performance: >> http://people.freebsd.org/~mav/devstat_time.patch >> >> Are there any objections against it? > > No objections here, but I wonder if you were able to compare the results > somehow before and after the change so we have some hard numbers to show > that we don't lose much by applying the change. I haven't tested it statistically, but I haven't noticed any visual difference in gstat output with its 0.1ms displayed resolution. > On a mostly unrelated note when two threads (T0 and T1) call get*time() > on two different cores, but T0 does that a bit earlier is it possible > that T0 can get later time than T1? There is no any locking or memory barriers in get*time(), so CPU is free to do some prefetching and out-of-order execution, slightly blurring "a bit earlier" concept. Except such close cases I believe it should not happen. -- Alexander Motin