All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Yuehai Xu <yuehaixu@gmail.com>
Cc: xen-devel@lists.xensource.com, yhxu@wayne.edu
Subject: Re: Question about the ability of credit scheduler to handle I/O and CPU intensive VMs
Date: Thu, 30 Sep 2010 14:27:37 +0100	[thread overview]
Message-ID: <AANLkTi=Oa0_=vXrr63eALBU2sQa3aLV0NiQHt8hPPvcw@mail.gmail.com> (raw)
In-Reply-To: <AANLkTikBWZdpOviSEQSNi_pf66A+zYW8FyQVjiCX8ojm@mail.gmail.com>

On Thu, Sep 30, 2010 at 1:28 PM, Yuehai Xu <yuehaixu@gmail.com> wrote:
>> I agree, letting a VM with an interrupt run for a short period of time
>> makes sense.  The challenge is to make sure that it can't simply send
>> itself interrupts every 50us and get to run 100% of the time. :-)
>
> I am afraid I don't really understand the challenge is, or, in another
> word, this method is good principally, but in practice, it is hard to
> implement? As I know, the OS should always schedules I/O related
> processes once they are in runnable queue, so, as long as we give even
> a very short period of time to the waken up guest VM, the I/O process
> in it should be scheduled at once. In that case, this problem should
> be solved. Of course, I don't do experiments, saying is always much
> easier than doing.

What I mean is that you have to be careful when implementing it.  A
very simple implementation would look like this:
* Normally, let the VM with the highest credits run.  However, if a VM
is sent an interrupt, give it priority to run for 50us.

Now, suppose, however, that a rogue VM sets up a periodic timer to
send itself an interrupt every 55us.  Then it will get an interrupt,
get priority for 50us, be preempted for 5us, and then get another
interrupt, allowing it to run for another 50us.    Thus it runs 90% of
the time, even though it should only run (for example) 50% of the
time.

We need a way to balance interrupt latency (how long after an
interrupt is raised before a VM can run) and cpu scheduling fairness.
That means that if we let a VM run for 50us, and then preempt it, and
it gets an interrupt 5us later, we need a way to know not to schedule
it until it's been off the cpu for a reasonable amount of time.  It's
possible, but it will take some experimentation to see what the best
option is.

 -George

>
> Thanks,
> Yuehai
>>
>> I don't have time to work on this right now, but if you work up some
>> patches, I can give you feedback.  Be advised, that getting this stuff
>> to work right is not easy.
>>
>>  -George
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

  reply	other threads:[~2010-09-30 13:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-13 21:37 Question about the ability of credit scheduler to handle I/O and CPU intensive VMs Yuehai Xu
2010-09-13 23:29 ` Jeremy Fitzhardinge
2010-09-14  1:38   ` Yuehai Xu
     [not found] ` <AANLkTin9E1m_jFcj4Ak7nB9OxcQynrznpQ_nNPi_U7hN@mail.gmail.com>
2010-09-14 14:58   ` Yuehai Xu
2010-09-30 12:28   ` Yuehai Xu
2010-09-30 13:27     ` George Dunlap [this message]
2010-10-05  2:52       ` Yuehai Xu
2010-10-05 14:16         ` George Dunlap
2010-10-05 14:56           ` Yuehai Xu
2010-10-05 15:02             ` George Dunlap
2010-10-07 22:18               ` Yuehai Xu
2010-10-08  0:25                 ` Yuehai Xu
2010-10-08  9:57                   ` George Dunlap
2010-10-08 10:03                     ` George Dunlap
2010-10-08 10:11                       ` George Dunlap
2010-10-10  4:08                     ` Yuehai Xu
2010-10-10  8:30                       ` cendhu
2010-10-11 11:05                       ` George Dunlap
2010-10-12 12:42                         ` Yuehai Xu
2010-10-18 10:25                           ` George Dunlap
2010-10-05  4:30       ` question about lineat pagetable and mfn_x strongerwill

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='AANLkTi=Oa0_=vXrr63eALBU2sQa3aLV0NiQHt8hPPvcw@mail.gmail.com' \
    --to=george.dunlap@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=yhxu@wayne.edu \
    --cc=yuehaixu@gmail.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 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.