All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuehai Xu <yuehaixu@gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.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: Tue, 5 Oct 2010 10:56:13 -0400	[thread overview]
Message-ID: <AANLkTinCbnzLLtNpdQe0x387UeDcy3SzrmffZw1oQAJo@mail.gmail.com> (raw)
In-Reply-To: <AANLkTintdF5h0-YD6FxjX0dapfbQYdAcK2P-=wHXnBiC@mail.gmail.com>

On Tue, Oct 5, 2010 at 10:16 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> On Tue, Oct 5, 2010 at 3:52 AM, Yuehai Xu <yuehaixu@gmail.com> wrote:
>> However, I stop one of the CPU intensive program in a DomU while keep
>> the other running, the results are:
>> .....
>> <  0.327815345 |x d1v0> (dom: 1) --> (dom: 2) vruntime : 1542607)
>> <  0.327906620 -x d2v0> (dom: 2) --> (dom: 1) vruntime : 109521)
>> <  0.344349033 |x d1v0> (dom: 1) --> (dom: 2) vruntime : 19779544)
>> <  0.344377129 -x d2v0> (dom: 2) --> (dom: 1) vruntime : 33528)
>> <  0.344570662 |x d1v0> (dom: 1) --> (dom: 2) vruntime : 232540)
>> <  0.344643933 -x d2v0> (dom: 2) --> (dom: 1) vruntime : 87857)
>> <  0.345009170 |x d1v0> (dom: 1) --> (dom: 2) vruntime : 439081)
>> <  0.345034387 -x d2v0> (dom: 2) --> (dom: 1) vruntime : 30059)
>> <  0.369973183 -x d1v0> (dom: 1) --> (dom: 1) vruntime : 30000506)
>> <  0.392423279 |x d1v0> (dom: 1) --> (dom: 2) vruntime : 27006658)
>> ....
>>
>> Here I am gotten confusing, since my algorithm of scheduling is very
>> simple, every VM should have 30ms of PCPU, however, from the results,
>> the time for
>> each VCPU to have PCPU is quite unstable. I think somewhere, the
>> routine of schedule() should be invoked frequently, and from xentop,
>> the VM with CPU
>> intensive occupies PCPU almost at 97%.
>
> Idle VMs are never 100% idle; there are a lot of "maintenance" tasks
> still to be done.
>
> Your mostly-idle domain (domain 2) seems to be running for pretty
> short periods of time -- less than 100us.  That's pretty reasonable.
>
> The question to ask is, what happens when domain 2 wakes up -- is it
> put on the runqueue, waiting for the running domain to finish its
> timeslice?  Or is it run immediately?  Given the trace you give here,
> I would guess that it's run immediately.  If that's not what you
> expect, you need to figure out why it's doing that and make it do
> something else. :-)

Yes, you are right, when domain 2 is waken up, it will be inserted to
the head of the scheduling list, and then, run immediately. This is
what I expect. I am sorry that I don't express the question clearly.

You have said that the mostly-idle domain should be running for a
pretty short periods of time, however, according to my understanding,
it is the scheduler to decide how long a domain should run. Since this
time is a fixed value, that is 30ms in my scheduler. What I am puzzled
is that why the running time for this mostly-idle domain is so short.
Is it because this domain idle? Or this domain is actually put into
other lists instead of runnable? is there other places that affect how
to schedule the VMs except such as csched_credit.c?

I know in the kernel of Linux, when a process is stocked because of
I/O, it will be deleted from runnable queue, so that the scheduler of
CPU can select next runnable process immediately. However, I thought
this was different from the scheduling of XEN. Since the scheduler
didn't really know whether the VCPU was consuming PCPU, it just
provided a certain period of time to the VM. I might be wrong. If it
is true, even a most idle VM should always consumes as the same PCPU
time as the busy one  in my scheduler. But the result is opposite. The
idle VM consumes much less PCPU then the busy one. This should not be
determined by the scheduling itself, otherwise, the idle one should
also have 50% PCPU. Then, what mechanism cause this result?

I really appreciate your help.

Thanks,
Yuehai

  reply	other threads:[~2010-10-05 14:56 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
2010-10-05  2:52       ` Yuehai Xu
2010-10-05 14:16         ` George Dunlap
2010-10-05 14:56           ` Yuehai Xu [this message]
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=AANLkTinCbnzLLtNpdQe0x387UeDcy3SzrmffZw1oQAJo@mail.gmail.com \
    --to=yuehaixu@gmail.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=yhxu@wayne.edu \
    /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.