xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Meng Xu <xumengpanda@gmail.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Tianyang Chen <tiche@seas.upenn.edu>,
	George Dunlap <george.dunlap@citrix.com>,
	Dagaen Golomb <dgolomb@seas.upenn.edu>,
	Meng Xu <mengxu@cis.upenn.edu>
Subject: Re: [PATCH v7]xen: sched: convert RTDS from time to event driven model
Date: Thu, 10 Mar 2016 11:38:11 +0100	[thread overview]
Message-ID: <1457606291.3102.473.camel@citrix.com> (raw)
In-Reply-To: <CAENZ-+=2R7st5jP6fKMmt61_AFQy16iT01oGS_5+iSCFXJ4o+Q@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3143 bytes --]

On Wed, 2016-03-09 at 23:00 -0500, Meng Xu wrote:
> On Wed, Mar 9, 2016 at 10:46 AM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> > 
> > Basically, by doing all the replenishments (which includes updating
> > all
> > the deadlines) upfront, we should be able to prevent the above
> > situation.
> > 
> > So, again, thoughts?
> I think we need to decide which vcpu is on depleted q before update
> deadline and we also need to record which vcpus should be updated. 
>
I think you are right about the need of a depleted flag, or something
that will have the same effect (but I really do like using a flag for
that! :-D ).

I don't think we really need to count anything. In fact, what I had in
mind and tried to put down in pseudocode is that we traverse the list
of replenishment events twice. During the first traversal, we do not
remove the elements that we replenish (i.e., the ones that we call
rt_update_deadline() on). Therefore, we can just do the second
traversal, find them all in there, handle the tickling, and --in this
case-- remove and re-insert them. Wouldn't this work?

> So
> I added some code into your code:
> 
> #define __RTDS_is_depleted     3
> #define RTDS_is_depleted  (1<<__RTDS_is_depleted)
> 
As said, I like this. However...

> int num_repl_vcpus = 0;
>  for_each_to_be_replenished_vcpu(v)
>  {
>    if (v->cur_budget <= 0)
>        set_bit(__RTDS_is_depleted, &v->flags);
> 
... I think we can do this in burn_budget(), where we have this check
in place already.

>     rt_update_deadline(v);
>     num_repl_vcpus++;
>  }
> 
>   for_each_to_be_replenished_vcpu(v)
>   {
>     deadline_queue_remove(replq, v);
> 
>     if ( curr_on_cpu(v->processor) == v)) //running
>     {
>         if ( v->cur_deadline >= runq[0]->cur_deadline )
>           tickle(runq[0]); /* runq[0] => first vcpu in the runq */
>     }
>     else if ( __vcpu_on_q(v) )
>     {
>         if ( v->flags & RTDS_is_depleted )         //depleted
>         {
>           clear_bit(__RTDS_is_depleted, &v->flags);
>
 if ( test_and_clear(xxx) )

Or __test_and_clear(xxx).

>           tickle(v);
>         }
>         else                              //runnable
>           /* do nothing */
>     }
>     deadline_queue_insert(v, replq);
> 
>     /* stop at the vcpu that does not need replenishment */
>     num_repl_vcpus--;
>     if (!num_repl_vcpus)
>         break;
>
If we really need to record/mark this, I want to think at how that
would be best done, as I'm not a fan of this counting... But hopefully,
we just don't need to do anything like that, do we?

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-03-10 10:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-05  1:39 [PATCH v7]xen: sched: convert RTDS from time to event driven model Tianyang Chen
2016-03-09  4:33 ` Meng Xu
2016-03-09 15:46   ` Dario Faggioli
2016-03-10  4:00     ` Meng Xu
2016-03-10 10:38       ` Dario Faggioli [this message]
2016-03-10 15:28         ` Meng Xu
2016-03-10 16:43           ` Dario Faggioli
2016-03-10 18:08             ` Meng Xu
2016-03-10 23:53               ` Dario Faggioli
2016-03-11  0:33                 ` Meng Xu

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=1457606291.3102.473.camel@citrix.com \
    --to=dario.faggioli@citrix.com \
    --cc=dgolomb@seas.upenn.edu \
    --cc=george.dunlap@citrix.com \
    --cc=mengxu@cis.upenn.edu \
    --cc=tiche@seas.upenn.edu \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xumengpanda@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).