From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO
 hypercall\
Date: Thu, 28 Sep 2017 18:41:21 -0300
Message-ID: <20170928214121.GA16169@amt.cnet>
References: <20170923134114.qdfdegrd6afqrkut@hirez.programming.kicks-ass.net>
 <855950672.7912001.1506258344142.JavaMail.zimbra@redhat.com>
 <20170925025751.GB30813@amt.cnet>
 <20170925091316.bnwpiscs2bvpdxk5@hirez.programming.kicks-ass.net>
 <00ff8cbf-4e41-a950-568c-3bd95e155d4b@redhat.com>
 <20170926224925.GA9119@amt.cnet>
 <6f4afefd-8726-13ff-371e-0d3896b4cf6a@redhat.com>
 <20170928004452.GA30040@amt.cnet>
 <10635834-459a-9ec1-624d-febd6b5af243@redhat.com>
 <20170928213508.GA14053@amt.cnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Peter Zijlstra <peterz@infradead.org>,
        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
        mingo@redhat.com, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20170928213508.GA14053@amt.cnet>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On Thu, Sep 28, 2017 at 06:35:08PM -0300, Marcelo Tosatti wrote:
> On Thu, Sep 28, 2017 at 09:22:02AM +0200, Paolo Bonzini wrote:
> > On 28/09/2017 02:44, Marcelo Tosatti wrote:
> > >> Again: if you have many interruptions, it's not a flaw in KVM or QEMU's
> > >> design, it's just that someone is doing something stupid.  It could be
> > >> the guest (e.g. unnecessary devices or daemons as in the example above),
> > >> QEMU (e.g. the RTC emulation used to trigger QEMU timers twice a second
> > >> just to increment the clock), or the management (e.g. polling "is the VM
> > >> running" 50 times per second).  But it can and must be fixed.
> > >
> > > No, i mean you can run anything in VCPU-0 (it is valid to do that).
> > > And that "anything" can generate 1 interrupt per second, 1000 or 10.000
> > > interrupts per second. Which are all valid things to be done.
> > > 
> > > "I can't run a kernel compilation on VCPU-0 because that will impact
> > > latency on the realtime VCPU-1" is not acceptable.
> > 
> > That shouldn't happen.  Sources of frequent interruptions have all been
> > fixed or moved outside the main thread.
> > 
> > If there are more left, report the bug and we'll see how to fix it in
> > userspace.
> > 
> > Paolo
> 
> What should not happen? The generation of 10.000 interrupts per second
> (say disk IO completion) on a given workload ?

Are you suggesting that, workloads in vcpu-0 should be limited in the number
of interrupts (and durations of each interruption), so that the realtime vcpu-1's
latency requirement is met ?

I don't see how that suggestion can work because even if you make each
exit small, the frequency of them will cause a latency violation on
vcpu-1.