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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
