On Wed, Nov 27, 2013 at 01:05:40PM +0200, Abel Gordon wrote: > > > (CCing Eyal Moscovici who is actually prototyping with multiple > > > policies and may want to join this thread) > > > > > > Starting with basic policies: we can use a single vhost thread > > > and create new vhost threads if it becomes saturated and there > > > are enough cpu cycles available in the system > > > or if the latency (how long the requests in the virtio queues wait > > > until they are handled) is too high. > > > We can merge threads if the latency is already low or if the threads > > > are not saturated. > > > > > > There is a hidden trade-off here: when you run more vhost threads you > > > may actually be stealing cpu cycles from the vcpu threads and also > > > increasing context switches. So, from the vhost perspective it may > > > improve performance but from the vcpu threads perspective it may > > > degrade performance. > > > > So this is a very interesting problem to solve but what does > > management know that suggests it can solve it better? > > Yep, and Eyal is currently working on this. > What the management knows ? depends who the management is :) > Could be just I/O activity (black-box: I/O request rate, I/O > handling rate, latency) We know much more about this than managament, don't we? > or application performance (white-box). This would have to come with a proposal for getting this white-box info out of guest somehow. -- MSR -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
