public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: vatsa@linux.vnet.ibm.com
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>,
	linux-kernel@vger.kernel.org, npiggin@suse.de,
	kvm@vger.kernel.org, bharata@in.ibm.com,
	Balbir Singh <balbir@in.ibm.com>,
	Jan Beulich <JBeulich@novell.com>
Subject: Re: [PATCH RFC 2/4] Add yield hypercall for KVM guests
Date: Mon, 02 Aug 2010 11:40:23 +0300	[thread overview]
Message-ID: <4C568477.4000602@redhat.com> (raw)
In-Reply-To: <20100728145516.GB27739@linux.vnet.ibm.com>

  On 07/28/2010 05:55 PM, Srivatsa Vaddagiri wrote:
> On Mon, Jul 26, 2010 at 10:19:41AM -0700, Jeremy Fitzhardinge wrote:
>>   On 07/25/2010 11:14 PM, Srivatsa Vaddagiri wrote:
>>> Add KVM hypercall for yielding vcpu timeslice.
>> Can you do a directed yield?
> We don't have that support yet in Linux scheduler.

If you think it's useful, it would be good to design it into the 
interface, and fall back to ordinary yield if the host doesn't support it.

A big advantage of directed yield vs yield is that you conserve 
resources within a VM; a simple yield will cause the guest to drop its 
share of cpu to other guest.

Made up example:

- 2 vcpu guest with 10% contention
- lock hold time 10us every 100us
- timeslice 1ms

Ideally this guest can consume 190% cpu (sleeping whenever there is 
contention).  But if we yield when we detect contention, then we sleep 
for 1ms, and utilization drops to around 100%-150% (a vcpu will usually 
fall asleep soon within a few 100us periods).

> Also I feel it would be more
> useful when the target vcpu and yielding vcpu are on the same physical cpu,
> rather than when they are on separate cpus. With latter, yielding (or
> donating) timeslice need not ensure that target vcpu runs immediately

Donate at least the amount needed to wake up the other vcpu, we can 
calculate it during wakeup.

> and also I suspect fairness issues needs to be tackled as well (large number of
> waiters shouldn't boot a lock-holders time slice too much that it gets a
> larger share).

I feel ordinary yield suffers from fairness a lot more.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2010-08-02  8:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-26  6:11 [PATCH RFC 0/4] Paravirt-spinlock implementation for KVM guests (Version 0) Srivatsa Vaddagiri
2010-07-26  6:13 ` [PATCH RFC 1/4] Debugfs support for reading an array of u32-type integers Srivatsa Vaddagiri
2010-07-26  6:14 ` [PATCH RFC 2/4] Add yield hypercall for KVM guests Srivatsa Vaddagiri
2010-07-26 17:19   ` Jeremy Fitzhardinge
2010-07-28 14:55     ` Srivatsa Vaddagiri
2010-08-02  8:40       ` Avi Kivity [this message]
2010-08-03  5:16         ` Srivatsa Vaddagiri
2010-08-03  5:33           ` Srivatsa Vaddagiri
2010-08-02  8:32     ` Avi Kivity
2010-08-02 14:42       ` Ryan Harper
2010-08-02 14:50         ` Avi Kivity
2010-08-02 15:08       ` Jeremy Fitzhardinge
2010-07-26  6:15 ` [PATCH RFC 3/4] Paravirtualized spinlock implementation " Srivatsa Vaddagiri
2010-08-02  8:48   ` Avi Kivity
2010-08-02 15:20     ` Jeremy Fitzhardinge
2010-08-03  6:59       ` Avi Kivity
2010-08-03 17:47         ` Jeremy Fitzhardinge
2010-08-02  8:53   ` Avi Kivity
2010-07-26  6:16 ` [PATCH RFC 4/4] Add yield hypercall support in Qemu Srivatsa Vaddagiri
2010-07-26 17:18 ` [PATCH RFC 0/4] Paravirt-spinlock implementation for KVM guests (Version 0) Jeremy Fitzhardinge
2010-07-28 14:47   ` Srivatsa Vaddagiri
2010-07-28 22:10 ` Konrad Rzeszutek Wilk
2010-07-28 22:42   ` Konrad Rzeszutek Wilk
2010-08-02  8:50 ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C568477.4000602@redhat.com \
    --to=avi@redhat.com \
    --cc=JBeulich@novell.com \
    --cc=balbir@in.ibm.com \
    --cc=bharata@in.ibm.com \
    --cc=gleb@redhat.com \
    --cc=jeremy@goop.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=npiggin@suse.de \
    --cc=vatsa@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox