Re: faster timecounters for kvm/xen

2017-06-18 Thread Mike Belopuhov
On Sun, Jun 18, 2017 at 21:20 +1000, Jonathan Matthew wrote: > On Fri, Jun 16, 2017 at 10:25:29AM +0200, Mike Belopuhov wrote: > > Now regarding the diff. pvbus_init_vcpu. Ah yes, please. > > It was a chicken and the egg problem for me: I didn't have > > Xen, but wanted a callback from cpu_hatch

Re: faster timecounters for kvm/xen

2017-06-18 Thread Jonathan Matthew
On Fri, Jun 16, 2017 at 10:25:29AM +0200, Mike Belopuhov wrote: > On Fri, Jun 16, 2017 at 16:31 +1000, Jonathan Matthew wrote: > > Recently I updated the kernel lock profiling stuff I've been working on, > > since > > it had been rotting a bit since witness was introduced. Running my diff > > o

Re: faster timecounters for kvm/xen

2017-06-17 Thread Mike Belopuhov
On 17 June 2017 at 14:17, Jonathan Matthew wrote: > > On Fri, Jun 16, 2017 at 01:19:02PM +0200, Mike Belopuhov wrote: > > On Fri, Jun 16, 2017 at 10:25 +0200, Mike Belopuhov wrote: > > > I don't know if it's a good idea to depend on Xen's > > > definition of vcpu_time_info. I think I have factore

Re: faster timecounters for kvm/xen

2017-06-17 Thread Jonathan Matthew
On Fri, Jun 16, 2017 at 01:19:02PM +0200, Mike Belopuhov wrote: > On Fri, Jun 16, 2017 at 10:25 +0200, Mike Belopuhov wrote: > > I don't know if it's a good idea to depend on Xen's > > definition of vcpu_time_info. I think I have factored > > it out into the pvclock_time_info and put it into the >

Re: faster timecounters for kvm/xen

2017-06-16 Thread Mike Larkin
On Fri, Jun 16, 2017 at 11:09:01PM +1000, Jonathan Gray wrote: > On Fri, Jun 16, 2017 at 02:23:36PM +0200, Mike Belopuhov wrote: > > On Fri, Jun 16, 2017 at 16:31 +1000, Jonathan Matthew wrote: > > > Index: arch/i386/include/cpufunc.h > > > ==

Re: faster timecounters for kvm/xen

2017-06-16 Thread Mike Belopuhov
On Fri, Jun 16, 2017 at 10:25 +0200, Mike Belopuhov wrote: > Last time I've tried uebayashi's pvclock on Xen, it didn't > work for me. I didn't have time to investigate why but > probably because we need per-cpu readings. Which you do > for KVM. I'll test this on Xen as soon as I get to the > of

Re: faster timecounters for kvm/xen

2017-06-16 Thread Mike Belopuhov
On Fri, Jun 16, 2017 at 23:09 +1000, Jonathan Gray wrote: > On Fri, Jun 16, 2017 at 02:23:36PM +0200, Mike Belopuhov wrote: > > On Fri, Jun 16, 2017 at 16:31 +1000, Jonathan Matthew wrote: > > > Index: arch/i386/include/cpufunc.h > > > ===

Re: faster timecounters for kvm/xen

2017-06-16 Thread Jonathan Gray
On Fri, Jun 16, 2017 at 02:23:36PM +0200, Mike Belopuhov wrote: > On Fri, Jun 16, 2017 at 16:31 +1000, Jonathan Matthew wrote: > > Index: arch/i386/include/cpufunc.h > > === > > RCS file: /cvs/src/sys/arch/i386/include/cpufunc.h,v > >

Re: faster timecounters for kvm/xen

2017-06-16 Thread Mike Belopuhov
On Fri, Jun 16, 2017 at 16:31 +1000, Jonathan Matthew wrote: > Index: arch/i386/include/cpufunc.h > === > RCS file: /cvs/src/sys/arch/i386/include/cpufunc.h,v > retrieving revision 1.25 > diff -u -p -u -p -r1.25 cpufunc.h > --- arch/i3

Re: faster timecounters for kvm/xen

2017-06-16 Thread Mike Belopuhov
On Fri, Jun 16, 2017 at 10:25 +0200, Mike Belopuhov wrote: > I don't know if it's a good idea to depend on Xen's > definition of vcpu_time_info. I think I have factored > it out into the pvclock_time_info and put it into the > pvclockvar.h or something like that. And then made Xen > use those def

Re: faster timecounters for kvm/xen

2017-06-16 Thread Mike Belopuhov
On Fri, Jun 16, 2017 at 16:31 +1000, Jonathan Matthew wrote: > Recently I updated the kernel lock profiling stuff I've been working on, since > it had been rotting a bit since witness was introduced. Running my diff on a > KVM VM, I found there was a pretty huge performance impact (10 minutes to

faster timecounters for kvm/xen

2017-06-15 Thread Jonathan Matthew
Recently I updated the kernel lock profiling stuff I've been working on, since it had been rotting a bit since witness was introduced. Running my diff on a KVM VM, I found there was a pretty huge performance impact (10 minutes to build a kernel instead of 4), which turned out to be because readin