On Mon, Mar 26, 2018 at 02:54:45PM +0000, Wang, Wei W wrote: > On Monday, March 26, 2018 7:09 PM, Daniel P. Berrangé wrote: > > > > As far as libvirt is concerned there are three sets of threads it provides > > control over > > > > - vCPUs - each VCPU in KVM has a thread. Libvirt provides per-thread > > tunable control > > > > - IOThreads - each named I/O thread can be associated with one or more > > devices. Libvirt provides per-thread tunable control. > > > > - Emulator - any other QEMU thread which isn't an vCPU thread or IO thread > > gets called an emulator thread by libvirt. There is no-per thread > > tunable control - we can set tunables for entire set of emulator threads > > at once. > > > > > Hi Daniel, > Thanks for sharing the details, they are very helpful. I still have a > question: > > There is no fundamental difference between iothread and our optimization > thread (it is similar to the migration thread, which is created when > migration begins and terminated when migration is done) - both of them are > pthreads and each has a name. Could we also add the similar per-thread > tunable control in libvirt for such threads? > > For example, in QEMU we can add a new migration qmp command, > migrate_enable_free_page_optimization (just like other commands > migrate_set_speed 10G), this command will create the optimization thread. > In this way, creation of the thread is in libvirt's control, and libvirt > can then support tuning the thread (e.g. pin it to any pCPU), right?
Anything is possible from a technical level, but from a design POV we would rather not start exposing tunables for arbitrary device type specific threads as they are inherantly non-portable and may not even exist in QEMU long term as it is just an artifact of the current QEMU implementation. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
