From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: Elvis upstreaming plan Date: Wed, 27 Nov 2013 13:40:03 +0200 Message-ID: <20131127114003.GG29702@redhat.com> References: <87r4a3avjn.fsf@codemonkey.ws> <20131126211157.GC26547@redhat.com> <20131127092100.GG28488@redhat.com> <20131127102943.GD29446@redhat.com> <20131127110325.GE29702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abel.gordon@gmail.com, Anthony Liguori , digitaleric@google.com, Eran Raichstein , Eyal Moscovici , gleb@redhat.com, jasowang@redhat.com, Joel Nider , kvm@vger.kernel.org, pbonzini@redhat.com, Razya Ladelsky , Yossi Kuperman1 To: Abel Gordon Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43693 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269Ab3K0Lgz (ORCPT ); Wed, 27 Nov 2013 06:36:55 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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