public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Avi Kivity <avi@redhat.com>
Cc: Rik van Riel <riel@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Chris Wright <chrisw@sous-sol.org>
Subject: Re: [RFC -v2 PATCH 2/3] sched: add yield_to function
Date: Fri, 17 Dec 2010 20:51:49 +0100	[thread overview]
Message-ID: <1292615509.7381.81.camel@marge.simson.net> (raw)
In-Reply-To: <4D0B7D24.5060207@redhat.com>

On Fri, 2010-12-17 at 17:09 +0200, Avi Kivity wrote:
> On 12/17/2010 08:56 AM, Mike Galbraith wrote:
> > >  Surely that makes it a reasonable idea to call yield, and
> > >  get one of the other tasks on the current CPU running for
> > >  a bit?
> >
> > There's nothing wrong with trying to give up the cpu.  It's the concept
> > of a cross cpu yield_to() that I find mighty strange.
> 
> What's so strange about it?  From a high level there are N runnable 
> tasks contending for M cpus.  If task X really needs task Y to run, what 
> does it matter if task Y last ran on the same cpu as task X or not?

Task X wants control of when runnable task Y gets the cpu.  Task X
clearly wants to be the scheduler.  This isn't about _yielding_ diddly
spit, it's about individual tasks wanting to make scheduling decisions,
so calling it a yield is high grade horse-pookey.  You're trying to give
the scheduler a hint, the stronger that hint, the happier you'll be.

I can see the problem, and I'm not trying to be Mr. Negative here, I'm
only trying to point out problems I see with what's been proposed.  

If the yielding task had a concrete fee he could pay, that would be
fine, but he does not.

If he did have something, how often do you think it should be possible
for task X to bribe the scheduler into selecting task Y?  Will his
pockets be deep enough to actually solve the problem?  Once he's
yielded, he's out of the picture for a while if he really gave anything
up.  What happens to donated entitlement when the recipient goes to
sleep?  If you try to give it back, what happens if the donor exited?
Where did the entitlement come from if task A running alone on cpu A
tosses some entitlement over the fence to his pal task B on cpu B.. and
keeps on trucking on cpu A?  Where does that leave task C, B's
competition?

> Do I correctly read between the lines that CFS maintains complete 
> fairness only on a cpu, but not globally?

Nothing between the lines about it.  There are N individual engines,
coupled via load balancing.

	-Mike

  reply	other threads:[~2010-12-17 19:51 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-14  3:44 [RFC -v2 PATCH 0/3] directed yield for Pause Loop Exiting Rik van Riel
2010-12-14  3:45 ` [RFC -v2 PATCH 1/3] kvm: keep track of which task is running a KVM vcpu Rik van Riel
2010-12-14  3:46 ` [RFC -v2 PATCH 2/3] sched: add yield_to function Rik van Riel
2010-12-14  6:08   ` Mike Galbraith
2010-12-14 10:24     ` Srivatsa Vaddagiri
2010-12-14 11:03       ` Mike Galbraith
2010-12-14 11:26         ` Srivatsa Vaddagiri
2010-12-14 12:47           ` Mike Galbraith
2010-12-16 19:49     ` Rik van Riel
2010-12-17  6:56       ` Mike Galbraith
2010-12-17  7:15         ` Mike Galbraith
2010-12-18 17:08           ` Avi Kivity
2010-12-18 19:13             ` Mike Galbraith
2010-12-19  6:08               ` Avi Kivity
2010-12-20 15:40           ` Rik van Riel
2010-12-20 16:04             ` Mike Galbraith
2010-12-28  5:54               ` Mike Galbraith
2010-12-28 22:34                 ` Rik van Riel
2010-12-17 15:09         ` Avi Kivity
2010-12-17 19:51           ` Mike Galbraith [this message]
2010-12-18 17:02             ` Avi Kivity
2010-12-18 19:06               ` Mike Galbraith
2010-12-19  6:21                 ` Avi Kivity
2010-12-19 10:05                   ` Mike Galbraith
2010-12-19  9:19                     ` Avi Kivity
2010-12-19 11:18                       ` Mike Galbraith
2010-12-20  8:39                       ` Mike Galbraith
2010-12-20  8:45                         ` Avi Kivity
2010-12-20  8:55                           ` Mike Galbraith
2010-12-20  9:03                             ` Avi Kivity
2010-12-20  9:30                               ` Mike Galbraith
2010-12-20  9:46                                 ` Avi Kivity
2010-12-20 10:33                                   ` Mike Galbraith
2010-12-20 10:39                                     ` Avi Kivity
2010-12-20 10:46                                       ` Mike Galbraith
2010-12-20 10:49                                         ` Avi Kivity
2010-12-20 10:50                                           ` Mike Galbraith
2010-12-20 11:06                                             ` Avi Kivity
2010-12-14 12:22   ` Peter Zijlstra
2010-12-18 14:50     ` Rik van Riel
2010-12-14  3:48 ` [RFC -v2 PATCH 3/3] kvm: use yield_to instead of sleep in kvm_vcpu_on_spin Rik van Riel

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=1292615509.7381.81.camel@marge.simson.net \
    --to=efault@gmx.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=avi@redhat.com \
    --cc=chrisw@sous-sol.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --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