From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [QEMU patch 2/2] kvm: allow configuration of tsc deadline timer advancement Date: Wed, 10 Dec 2014 19:39:06 +0100 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 Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org, Luiz Capitulino , Rik van Riel To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49264 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932806AbaLJSjP (ORCPT ); Wed, 10 Dec 2014 13:39:15 -0500 Content-Disposition: inline In-Reply-To: <5488892C.7010606@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.)