Re: [PATCH RFC 0/2] kvm: Improving directed yield in PLE handler

From: Benjamin Herrenschmidt
Date: Wed Jul 11 2012 - 22:20:00 EST


On Wed, 2012-07-11 at 14:23 +0300, 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.

It historically was but that has changed quite a bit. Essentially the
user can configure partitions to be more of the "all virtualized" kind
or on the contrary more fixed partitions. The hypervisor does shared
processors and we have paravirt APIs to cede our time slice to the lock
holder.

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

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/