qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v5 4/5] virtio-balloon: VIRTIO_


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [virtio-dev] Re: [PATCH v5 4/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
Date: Mon, 26 Mar 2018 16:04:03 +0100
User-agent: Mutt/1.9.2 (2017-12-15)

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]