From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 0/8] use jump labels to streamline common APIC configuration Date: Tue, 14 Aug 2012 19:16:01 +0200 Message-ID: <502A87D1.3030303@siemens.com> References: <1344171513-4659-1-git-send-email-gleb@redhat.com> <501E760E.9050109@redhat.com> <20120805133549.GL27579@redhat.com> <501E7839.2030008@redhat.com> <20120805134842.GM27579@redhat.com> <501E7C85.70001@redhat.com> <20120805140305.GN27579@redhat.com> <502A5A16.6040506@siemens.com> <20120814140348.GM11194@redhat.com> <502A5E96.6090908@siemens.com> <20120814143758.GP11194@redhat.com> <502A67AC.3000209@siemens.com> <502A7AF6.7010609@redhat.com> <502A7F1A.8080102@siemens.com> <502A841F.40504@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , "kvm@vger.kernel.org" , "mtosatti@redhat.com" To: Avi Kivity Return-path: Received: from thoth.sbs.de ([192.35.17.2]:28719 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752140Ab2HNRQI (ORCPT ); Tue, 14 Aug 2012 13:16:08 -0400 In-Reply-To: <502A841F.40504@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-08-14 19:00, Avi Kivity wrote: > On 08/14/2012 07:38 PM, Jan Kiszka wrote: >> On 2012-08-14 18:21, Avi Kivity wrote: >>> On 08/14/2012 05:58 PM, Jan Kiszka wrote: >>>>>> >>>>>> And regarding how common they are: Do standard OSes trigger any >>>>>> jump-label optimized switch during at least their boot-up? I thought so. >>>>>> In that case, if you co-locate RT and standard OSes on a shared host, >>>>>> you would have a conflict. >>>>>> >>>>> Yes, during boot up it happens. But it is rate limited to happen not >>>>> more than once per second. But I genuinely curious does RT guest have >>>>> any RT guaranties from QEMU/kvm combination today (with of without >>>>> jump-labels)? >>>> >>>> Yes, when avoiding userspace exits. If you have a customized RTOS guest >>>> or are lucky with some existing one, that works pretty well for periodic >>>> processing in the 1 ms range. >>> >>> I'd have expected better. >> >> It can be but I would not yet count on it - therefore this conservative >> number. Also, the number of VM exists per period is, of course, an >> increasingly relevant factor when going down with the cycle time. So, >> actually, you can only define the latency as function of various >> workload parameters. > > Right. These can be divided into guest induced exits (like APIC writes) > and host induced exits (like external interrupts). The former would be > more predictable, while the latter can be part of the background load, > so I expect them to be more problematic. Does this match your experience? Yep. Thanks to CPU isolation, we can control the latter to some degree as well. > > There is ongoing work to reduce unneeded IPIs, or confine them to > affected processors, this should help us in the long run. Indeed. The vision is 100% guest/KVM load on a dedicated core. > >> >>> >>> For more formal support, we need some ioctl() to pre-populate mappings, >>> or perhaps extend mmu notifiers to report mlock un munlock operations >>> and take them as a hint to premap. >> >> Of course, we are doing mlockall(CURRENT|FUTURE) for RT. As unpopulated >> mappings it didn't show up as latency source so far, I haven't looked at >> this closer. Which mappings could still be unpopulated? > > I expect none, since the guest application probably touches all memory > as part of initialization. That's what I meant by "formal": it's a > latency source that doesn't occur in practice, but the host cannot > guarantee that. > > We need to examine anything that can synchronize_rcu(). Luckily I don't > think we have anything like that in normal paths anymore. Yep, that matches our observation - in a particular setup at least. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux