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? There is ongoing work to reduce unneeded IPIs, or confine them to affected processors, this should help us in the long run. > >> >> 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. -- error compiling committee.c: too many arguments to function -- 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
