Date: Mon, 15 Apr 2013 22:13:30 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: devstat overhead VS precision Message-ID: <516C515A.9090602@FreeBSD.org> In-Reply-To: <20130415184203.GA1839@garage.freebsd.pl> References: <51692C95.3010901@FreeBSD.org> <20130415184203.GA1839@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?516C515A.9090602>