On 01/22/2011 06:53 AM, Rik van Riel wrote:
The main question that remains is whether the PV ticketlocks are
a large enough improvement to also merge those. I expect they
will be, and we'll see so in the benchmark numbers.
The pathological worst-case of ticket locks in a virtual environment
On 01/22/2011 01:14 AM, Srivatsa Vaddagiri wrote:
Also it may be possible for the pv-ticketlocks to track owning vcpu and make use
of a yield-to interface as further optimization to avoid the
others-get-more-time problem, but Peterz rightly pointed that PI would be a
better solution there than
On Thu, Jan 20, 2011 at 09:56:27AM -0800, Jeremy Fitzhardinge wrote:
The key here is not to
sleep when waiting for locks (as implemented by current patch-series, which
can
put other VMs at an advantage by giving them more time than they are
entitled
to)
Why? If a VCPU can't
On 01/21/2011 09:02 AM, Srivatsa Vaddagiri wrote:
On Thu, Jan 20, 2011 at 09:56:27AM -0800, Jeremy Fitzhardinge wrote:
The key here is not to
sleep when waiting for locks (as implemented by current patch-series, which can
put other VMs at an advantage by giving them more time than they are
On Fri, Jan 21, 2011 at 09:48:29AM -0500, Rik van Riel wrote:
Why? If a VCPU can't make progress because its waiting for some
resource, then why not schedule something else instead?
In the process, something else can get more share of cpu resource than its
entitled to and that's where I was
On Wed, Jan 19, 2011 at 10:53:52AM -0800, Jeremy Fitzhardinge wrote:
The reason for wanting this should be clear I guess, it allows PI.
Well, if we can expand the spinlock to include an owner, then all this
becomes moot...
How so? Having an owner will not eliminate the need for
On Wed, Jan 19, 2011 at 10:53:52AM -0800, Jeremy Fitzhardinge wrote:
I didn't really read the patch, and I totally forgot everything from
when I looked at the Xen series, but does the Xen/KVM hypercall
interface for this include the vcpu to await the kick from?
My guess is not, since the
On Thu, 2011-01-20 at 17:29 +0530, Srivatsa Vaddagiri wrote:
If we had a yield-to [1] sort of interface _and_ information on which vcpu
owns a lock, then lock-spinners can yield-to the owning vcpu,
and then I'd nak it for being stupid ;-)
really, yield*() is retarded, never even consider
On Thu, Jan 20, 2011 at 02:41:46PM +0100, Peter Zijlstra wrote:
On Thu, 2011-01-20 at 17:29 +0530, Srivatsa Vaddagiri wrote:
If we had a yield-to [1] sort of interface _and_ information on which vcpu
owns a lock, then lock-spinners can yield-to the owning vcpu,
and then I'd nak it for
On 01/20/2011 03:42 AM, Srivatsa Vaddagiri wrote:
On Wed, Jan 19, 2011 at 10:53:52AM -0800, Jeremy Fitzhardinge wrote:
The reason for wanting this should be clear I guess, it allows PI.
Well, if we can expand the spinlock to include an owner, then all this
becomes moot...
How so? Having an
On 01/20/2011 03:59 AM, Srivatsa Vaddagiri wrote:
At least in the Xen code, a current owner isn't very useful, because we
need the current owner to kick the *next* owner to life at release time,
which we can't do without some structure recording which ticket belongs
to which cpu.
If we had a
Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
KVM_HC_WAIT_FOR_KICK blocks the calling vcpu until another vcpu kicks it or it
is woken up because of an event like interrupt.
KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu.
The presence of these hypercalls is
On Wed, 2011-01-19 at 22:42 +0530, Srivatsa Vaddagiri wrote:
Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
KVM_HC_WAIT_FOR_KICK blocks the calling vcpu until another vcpu kicks it or it
is woken up because of an event like interrupt.
KVM_HC_KICK_CPU allows the calling
On Wed, Jan 19, 2011 at 10:42:39PM +0530, Srivatsa Vaddagiri wrote:
Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
KVM_HC_WAIT_FOR_KICK blocks the calling vcpu until another vcpu kicks it or it
is woken up because of an event like interrupt.
One possibility is to extend this
On Wed, 2011-01-19 at 22:53 +0530, Srivatsa Vaddagiri wrote:
On Wed, Jan 19, 2011 at 10:42:39PM +0530, Srivatsa Vaddagiri wrote:
Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
KVM_HC_WAIT_FOR_KICK blocks the calling vcpu until another vcpu kicks it or
it
is woken up
On Wed, Jan 19, 2011 at 06:21:12PM +0100, Peter Zijlstra wrote:
I didn't really read the patch, and I totally forgot everything from
when I looked at the Xen series, but does the Xen/KVM hypercall
interface for this include the vcpu to await the kick from?
No not yet, for reasons you mention
On 01/19/2011 09:21 AM, Peter Zijlstra wrote:
On Wed, 2011-01-19 at 22:42 +0530, Srivatsa Vaddagiri wrote:
Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
KVM_HC_WAIT_FOR_KICK blocks the calling vcpu until another vcpu kicks it or
it
is woken up because of an event like
17 matches
Mail list logo
