devstat overhead VS precision

[Alexander Motin]

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