-Mark Langsdorf
Operating System Research Center
AMD
> -Original Message-
> From: Sheng Yang [mailto:sh...@linux.intel.com]
> Sent: Wednesday, July 08, 2009 12:20 AM
> To: Langsdorf, Mark
> Cc: Roedel, Joerg; pet...@infradead.org; Ingo Molnar;
> a...@redhat.com; kvm@vge
> Um, I am afraid we have the different result... With your
> scheduler patch, we got 1% more performance improvement
> in the quick test. Of course more tests are needed to
> find a better value of delay.
What was your test case? How many runs did you do?
My results had a lot of variance in the
> What's the differences wrt retry 1?
I'm using git format-patch as you requested.
> > This feature creates a new field in the VMCB called Pause
> > Filter Count. If Pause Filter Count is greater than 0 and
> > intercepting PAUSEs is enabled, the processor will increment
> > an internal counter
> Ingo Molnar wrote:
> > * Avi Kivity wrote:
> >
> >
> >>> I.e. the 3000 cycles value itself could be eliminated as well.
> >>> (with just a common-sense max of say 100,000 cycles enforced)
> >>>
> >> Yeah, though that has a much smaller effect as it's only
> >> responsible for a few
> >> Please dont even think about using yield for this though -
Oops. I'm glad I waited to get some benchmark results before
submitting that version.
> >> A gradual and linear back-off from the current timeline is
> >> more of a fair negotiation process between vcpus and
> >> results in more o
> > > Once we go change silicon, you might as well do it right.
> > >
> >
> > None of the major x86 vendors are under my control.
>
> I thought this patch came from AMD, who changed their silicon
> so 'solve' one of these virt problems.
Right, and the change we came up with was to provide
a
