On 06.03.20 12:38, Paolo Bonzini wrote: > On 06/03/20 11:20, David Hildenbrand wrote: >> Yeah, rwlocks are not optimal and I am still looking for better >> alternatives (suggestions welcome :) ). Using RCU might not work, >> because the rcu_read region might be too big (esp. while in KVM_RUN). >> >> I had a prototype which used a bunch of atomics + qemu_cond_wait. But it >> was quite elaborate and buggy. >> >> (I assume only going into KVM_RUN is really affected, and I do wonder if >> it will be noticeable at all. Doing an ioctl is always already an >> expensive operation.) >> >> I can look into per-cpu locks instead of the rwlock. > > Assuming we're only talking about CPU ioctls (seems like a good
Yeah, I guess most !CPU ioctls are done under the BQL. > approximation) maybe you could use start_exclusive/end_exclusive? The > current_cpu->in_exclusive_context assignments can be made conditional on > "if (current_cpu)". > > However that means you have to drop the BQL, see > process_queued_cpu_work. It may be a problem. Thanks, I'll look into that. I currently have a simple cpu->ioctl_mutex. Cheers! -- Thanks, David / dhildenb
