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. > > 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? 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
