On Thu, Oct 27, 2022, Wang, Wei W wrote: > On Thursday, October 27, 2022 8:10 AM, Sean Christopherson wrote: > > > +void vm_vcpu_threads_create(struct kvm_vm *vm, > > > + void *(*start_routine)(void *), uint32_t private_data_size) > > > > I vote (very strongly) to not deal with allocating private data. The private data > > isn't strictly related to threads, and the vast majority of callers don't need private > > data, i.e. the param is dead weight in most cases. > > > > And unless I'm missing something, it's trivial to move to a separate helper, > > though honestly even that seems like overkill. > > > > Wait, looking further, it already is a separate helper... Forcing a bunch of > > callers to specify '0' just to eliminate one function call in a handful of cases is not > > a good tradeoff. > > The intention was to do the allocation within one vm_for_each_vcpu() > iteration when possible. Just a micro-optimization, but no problem, we can keep > them separate if that looks better (simpler). Keep them separate, that level of optimization is not something that's ever going to be noticeable. I don't want to say that performance is an afterthought for KVM selftests, but in common code it's definitely way down the list of priorities because even the most naive implementation for things like configuring vCPUs is going to have a runtime measured in milliseconds.
