On 07/11/2012 02:52 PM, Alexander Graf wrote: > > On 11.07.2012, at 13:23, Avi Kivity wrote: > >> On 07/11/2012 02:16 PM, Alexander Graf wrote: >>>> >>>>> yes the data structure itself seems based on the algorithm >>>>> and not on arch specific things. That should work. If we move that to common >>>>> code then s390 will use that scheme automatically for the cases were we call >>>>> kvm_vcpu_on_spin(). All others archs as well. >>>> >>>> ARM doesn't have an instruction for cpu_relax(), so it can't intercept >>>> it. Given ppc's dislike of overcommit, >>> >>> What dislike of overcommit? >> >> I understood ppc virtualization is more of the partitioning sort. >> Perhaps I misunderstood it. But the reliance on device assignment, the >> restrictions on scheduling, etc. all point to it. > > Well, you need to distinguish the different PPC targets here. In the embedded world, partitioning is obviously the biggest use case, though overcommit is possible. For big servers however, we usually do want overcommit and we do support it within the constraints hardware gives us. > > It's really no different from x86 when it comes to the use case wideness :). Okay, thanks for the correction. > >> >>> >>>> and the way it implements cpu_relax() by adjusting hw thread priority, >>> >>> Yeah, I don't think we can intercept relaxing. >> >> ... and the lack of ability to intercept cpu_relax() ... >> >>> It's basically a nop-like instruction that gives hardware hints on its current priorities. >> >> That's what x88 PAUSE does. But we can intercept it (and not just any >> execution - we can restrict intercept to tight loops executed more than >> a specific number of times). > > Yeah, it's pretty hard to fetch that information from PPC, since unlike x86 we split the hint from the loop. But I'll let Ben speak to that, he certainly knows way better how the hardware works. On x86 it's split from the loop as well (inside cpu_relax() like ppc). But the hardware detects the loop and lets us know about it. > >> >>> That said, we can always add PV code. >> >> Sure, but that's defeated by advancements like self-tuning PLE exits. >> It's hard to get this right. > > Well, eventually everything we do in PV is going to be moot as soon as hardware catches up. In most cases from what I've seen it's only useful as an interim solution. But for that time it's good to have :). Depends on how interim it is. If better hardware is coming, I'd rather not add more pv-ness. -- 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
