From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XylUh-0003zt-1i for qemu-devel@nongnu.org; Wed, 10 Dec 2014 12:56:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XylUa-0006fI-NU for qemu-devel@nongnu.org; Wed, 10 Dec 2014 12:56:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XylUa-0006ev-Fg for qemu-devel@nongnu.org; Wed, 10 Dec 2014 12:56:04 -0500 Message-ID: <5488892C.7010606@redhat.com> Date: Wed, 10 Dec 2014 18:55:56 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20141210162317.370733848@amt.cnet> <20141210162420.218207164@amt.cnet> <54887C61.80008@redhat.com> <20141210170405.GA19952@amt.cnet> <54887E3F.4030904@redhat.com> <20141210172712.GA20568@amt.cnet> <54888307.6020407@redhat.com> <20141210173554.GB21295@amt.cnet> In-Reply-To: <20141210173554.GB21295@amt.cnet> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [QEMU patch 2/2] kvm: allow configuration of tsc deadline timer advancement List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Luiz Capitulino On 10/12/2014 18:35, Marcelo Tosatti wrote: > On Wed, Dec 10, 2014 at 06:29:43PM +0100, Paolo Bonzini wrote: >> >> >> On 10/12/2014 18:27, Marcelo Tosatti wrote: >>> On Wed, Dec 10, 2014 at 06:09:19PM +0100, Paolo Bonzini wrote: >>>> >>>> >>>> On 10/12/2014 18:04, Marcelo Tosatti wrote: >>>>>> Please add an object property to the x86 CPU object. It can then be >>>>>> configured with "-global" on the command line. >>>>> >>>>> Don't want to allow individual values for different CPUs. >>>>> It is a per-VM property. >>>> >>>> Why? It can cause busy waiting, it would make sense to make it stricter >>>> for realtime CPUs and leave 0 for non-realtime CPUs. >>> >>> HW timer behaviour should be consistent across CPUs, IMO. >> >> It's not going to be anyway. Cache line bounces, frequency scaling, >> presence of higher-priority RT tasks, etc. can cause different response >> for one CPU over the others. > > OK i'll change it to per-CPU. Well, my preferred choice would be automatic adjustment with a module parameter. If we need manual tuning, per-CPU would be my choice, but automatic is nicer anyway. :) Paolo