From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XymAT-0007Pf-7Q for qemu-devel@nongnu.org; Wed, 10 Dec 2014 13:39:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XymAN-0006K0-3F for qemu-devel@nongnu.org; Wed, 10 Dec 2014 13:39:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XymAM-0006Is-RX for qemu-devel@nongnu.org; Wed, 10 Dec 2014 13:39:15 -0500 Date: Wed, 10 Dec 2014 19:39:06 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20141210183905.GA31236@potion.brq.redhat.com> 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> <5488892C.7010606@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5488892C.7010606@redhat.com> 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: Paolo Bonzini Cc: Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org, Luiz Capitulino 2014-12-10 18:55+0100, Paolo Bonzini: > 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. :) I agree with Paolo, and think it would be better not to touch QEMU ... it makes little sense to migrate this value and it is probably going to be quite similar on every CPU, so a writeable module parameter is a better starting point. (We can always turn it into a nightmare later.) If you measure the difference between the TSC you wanted and got on VM entry, you can use it to automatically guess a delta for the next timer. (That is IMO exactly what you would do with a manual tuning. The algorithm should probably prefer being a bit late than early too.)