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 :). > >> >>> 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. > >> 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 :). Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
