Messages in this thread | | | Date | Tue, 03 Aug 2010 09:59:16 +0300 | From | Avi Kivity <> | Subject | Re: [PATCH RFC 3/4] Paravirtualized spinlock implementation for KVM guests |
| |
On 08/02/2010 06:20 PM, Jeremy Fitzhardinge wrote: > On 08/02/2010 01:48 AM, Avi Kivity wrote: >> On 07/26/2010 09:15 AM, Srivatsa Vaddagiri wrote: >>> Paravirtual spinlock implementation for KVM guests, based heavily on >>> Xen guest's >>> spinlock implementation. >>> >>> >>> + >>> +static struct spinlock_stats >>> +{ >>> + u64 taken; >>> + u32 taken_slow; >>> + >>> + u64 released; >>> + >>> +#define HISTO_BUCKETS 30 >>> + u32 histo_spin_total[HISTO_BUCKETS+1]; >>> + u32 histo_spin_spinning[HISTO_BUCKETS+1]; >>> + u32 histo_spin_blocked[HISTO_BUCKETS+1]; >>> + >>> + u64 time_total; >>> + u64 time_spinning; >>> + u64 time_blocked; >>> +} spinlock_stats; >> >> Could these be replaced by tracepoints when starting to spin/stopping >> spinning etc? Then userspace can reconstruct the histogram as well >> as see which locks are involved and what call paths. > > Unfortunately not; the tracing code uses spinlocks. > > (TBH I haven't actually tried, but I did give the code an eyeball to > this end.)
Hm. The tracing code already uses a specialized lock (arch_spinlock_t), perhaps we can make this lock avoid the tracing?
It's really sad, btw, there's all those nice lockless ring buffers and then a spinlock for ftrace_vbprintk(), instead of a per-cpu buffer.
-- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
| |