In D29733#689273, @jhb wrote:

Does this supersede D29531? If so, should D29531 be abandoned with a pointer to this one?

Applies cleanly on 13.0-p1, all good so far.

In D29733#678871, @adam_fenn.io wrote:

Thanks again and, of course, any further feedback welcomed and appreciated!

In D29733#670409, @adam_fenn.io wrote:

Thanks in advance to anyone willing to review this and/or provide any feedback after taking it for a spin!

In D29733#668573, @adam_fenn.io wrote:

Thanks a lot for helping to test-drive this!

I applied the patch to my source tree and while compiling and using the kernel works perfectly, compiling libc failed:

In D29531#664831, @stevek wrote:

As I mentioned previously, my employer has contracted work to bring this driver to a full implementation. An initial draft is under review internally and a Phabricator review is queued up once we give the green light. That is why I suggested holding off on this version of the patch.

Oh fair enough, I'm uploading the newer version of the diff...

Adding kvmclock to FreeBSD

In D29531#664338, @rpokala wrote:

In addition to the copyright thing mentioned inline, a question: This is for FreeBSD VMs running under Linux Kernel-based Virtual Machine, correct?

I think this is how optional features work, let me know if I got it completely wrong. And sadly when arc diff --update really messes up with the notes, not sure if I'm using it wrong...

• Make kvm_clock an optional feature

• Used designated initializers
• Added a comment to explain what the magical | 1 means
• Removed useless variable

Here's what I get with doing random reads with fio on the device used by zfs (meaning I'm trying to see if the selected timecounter has an impact on the block device layer). Command used was:

fio --filename=/dev/vtbd0 --direct=1 --rw=randread --bs=4k --ioengine=posixaio --iodepth=256 --runtime=120 --numjobs=4 --time_based --group_reporting --name=iops-test-job --eta-newline=1 --readonly

In D29531#664236, @stevek wrote:

As I mentioned previously, the other thing to consider when using kvmclock in the current patch is the need for a system call for clock_gettime(), gettimeofday(), etc.

When using the TSC, one gets the advantage of timehands structures being updated in the shared memory page, that libc then can use without the need for a system call.
This is also true for HPET (although the HPET is usually a terrible clock source for VM guests) and the reference TSC in Hyper-V deployments.

In D29531#664230, @afedorov wrote:

@me_freebsd_mathieu.digital, what a CPU model was used for testing?

In D29531#663885, @stevek wrote:

That work is actively in progress.

Therefore, we may want to hold off trying to commit something right now.

• Removed headers as requested

In D29531#663896, @imp wrote:

A number of people are reporting problems with zfs scrub w/o this fix that they say is corrected by this, so there's some desirer to have it in the tree. Do you know if these setups are common? Or do you have a notion of why these results have been reported in light of this instability?

Sounds good, I will wait to hear from him before updating the diff.