All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.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>,
	peterz@infradead.org, mingo@elte.hu, efault@gmx.de
Subject: Re: [PATCH RFC 2/4] Add yield hypercall for KVM guests
Date: Tue, 3 Aug 2010 11:03:27 +0530	[thread overview]
Message-ID: <20100803053327.GC29526@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100803051659.GB29526@linux.vnet.ibm.com>

On Tue, Aug 03, 2010 at 10:46:59AM +0530, Srivatsa Vaddagiri wrote:
> On Mon, Aug 02, 2010 at 11:40:23AM +0300, Avi Kivity wrote:
> > >>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.
> 
> Hmm .. I see possibility of modifying yield to reclaim its "lost" timeslice when
> its scheduled next as well. Basically remember what timeslice we have given
> up and add that as its "bonus" when it runs next. That would keep the dynamics
> of yield donation/reclaim local to the (physical) cpu and IMHO is less complex
> than dealing with directed yield between tasks located across different physical
> cpus. That would also address the fairness issue with yield you are pointing at?

Basically with directed yield, we need to deal with these issues:

- Timeslice inflation of target (lock-holder) vcpu affecting fair-time of other
  guests vcpus.
- Intra-VM fairness - different vcpus could get different fair-time, depending
  on how much of a lock-holder/spinner a vcpu is

By simply educating yield to reclaim its lost share, I feel we can avoid these
complexities and get most of the benefit of yield-on-contention.

CCing other shceduler experts for their opinion of directed yield.

- vatsa

  reply	other threads:[~2010-08-03  5:33 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
2010-08-03  5:16         ` Srivatsa Vaddagiri
2010-08-03  5:33           ` Srivatsa Vaddagiri [this message]
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=20100803053327.GC29526@linux.vnet.ibm.com \
    --to=vatsa@linux.vnet.ibm.com \
    --cc=JBeulich@novell.com \
    --cc=avi@redhat.com \
    --cc=balbir@in.ibm.com \
    --cc=bharata@in.ibm.com \
    --cc=efault@gmx.de \
    --cc=gleb@redhat.com \
    --cc=jeremy@goop.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mtosatti@redhat.com \
    --cc=npiggin@suse.de \
    --cc=peterz@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.