From: Dagaen Golomb <dgolomb@seas.upenn.edu>
To: Meng Xu <xumengpanda@gmail.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Sisu Xi <xisisu@gmail.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
Dario Faggioli <dario.faggioli@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <jbeulich@suse.com>,
Chong Li <lichong659@gmail.com>
Subject: Re: [PATCH] Modified RTDS scheduler to use an event-driven model instead of polling.
Date: Wed, 17 Jun 2015 02:03:59 -0400 [thread overview]
Message-ID: <CALcuvTg1NNo+YU+HTCOkTKZZ4opBSAgg_ZjYk+PZk903vfoRHw@mail.gmail.com> (raw)
In-Reply-To: <CAENZ-+nfN6qm7XmQSnWns1FYjKNqEdZBkJFViCYaxMRSaBp0hw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4501 bytes --]
Thanks for the reply, budget enforcement in the scheduler timer makes
sense. I think I have an idea of what he wants done now.
~Dagaen
On Jun 17, 2015 1:45 AM, "Meng Xu" <xumengpanda@gmail.com> wrote:
> Hi Dagaen,
>
> I just comment on the summary of scheduler design you proposed at the
> end of the email. I'm looking forward to Dario's more insightful
> reply.
> >
> >
> > >
> > >> I simply
> > >> don't see how it can
> > >> be done without heavy interaction and information sharing between them
> > >> which really
> > >> defeats the purpose.
> > >>
> > > No, it doesn't.
> >
> > Ok this last line is the zinger.
> >
> > Almost this entire email was built on the premise that you would NOT
> like the
> > idea of the replenishment handler having basically the same decision
> logic
> > as the scheduler and then tickling the pCPU to pick up the new vCPU.
> Actually,
> > with it done this way, I would have a hard time calling the
> > tickle-invoked method
> > the "scheduler." It would be more like the mover, with the
> > replenishment function
> > being essentially the scheduler. In this case, I'm not too sure
> > actually how much
> > different this would be from what we have now. It feels like, from
> > what you want,
> > that we could get the same behavior by modifying rt_schedule to do
> > replenishments
> > first, then check if a reschedule is needed (these two parts would be in
> this
> > proposed replenishment timer routine) and the perform any move if
> necessary. I
> > know this isn't exactly what you want, but that sounds close right?
> >
> > But the scheduler will have to decide which to move in, so that logic
> > is done twice.
> > Also, if these are done back-to-back and require the locks, isn't it
> > really the same
> > as having one long hot path? If you want maintainability, couldn't we
> just do
> > replenishment then schedule and move (if necessary) in one timer (the
> > one we have
> > now) and move them to functions. It seems this can be done with one
> > timer neatly.
> >
> > So here's my proposal, lets see if it fits what you want:
>
>
> I will leave this to Dario to answer if it fits what he wants. :-P
>
>
> >
> > 1.) The scheduler does not do any timing,
>
>
> Not really. The rt_schedule does the budget enforcement. When a
> current VCPU runs out of budget, the rt_schedule will be invoked by a
> timer (you can refer to the schedule function in xen/sched/schedule.c
> to have a look how the timer is armed/disarmed.). When the rt_schedule
> is invoked, it needs to:
> a) update the budget of the current running VCPU and move it from runq
> to depleted queue;
> b) pick the current highest VCPU from runq and return it as the snext VCPU.
>
> So scheduling logic is still involved in the rt_schedule function.
>
> >
> > 2.) replenishments are scheduled via timer at each [next]
> > replenishment period. Each
> > replenishment resorts the replenished vCPUs, and if any of the first
> > #CPUs in the
> > runq change, we tickle a pCPU for each change
>
>
> This is right.
>
> >
> >
> > In this case, we can use one timer.
>
>
> We actually have two: one for budget enforcement and the other for
> budget replenishment.
>
>
> >
> > We could use the current one as a
> > replenishment
> > timer, and make it so rt_schedule isn't the default invoked method.
> >
> > Does this sound similar to what you are suggesting?
>
>
> I don't think so, but I will leave it for Dario's for his opinion.
>
> In Dario's suggestion, you just simply remove the update_budget
> function out of rt_schedule. This is because budget enforcement, which
> is the work of rt_schedule, does not naturelly involves budget
> replenishment.
>
> In order to achieve budget replenishment, we need another timer to
> invoke another function (budget_replenish function), that is dedicated
> to that.
>
> >
> > I have to ask
> > because I thought
> > you wouldn't like the idea,
>
>
> I guess Dario won't like this idea. :-P (I'm kidding, but it should be
> the case.)
>
>
> >
> > and its not really *that* far off from
> > what we have now, Its
> > a little restructuring so that replenishments occur before any
> > scheduling activity and
> > the handler checks if switching is needed (basically acting as the
> > scheduler) and then
> > calls tickle. Sounds like what you had in mind?
>
>
> Thanks and best regards,
>
> Meng
> --
>
>
> -----------
> Meng Xu
> PhD Student in Computer and Information Science
> University of Pennsylvania
> http://www.cis.upenn.edu/~mengxu/
>
[-- Attachment #1.2: Type: text/html, Size: 5593 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-06-17 6:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 11:46 [PATCH] Modified RTDS scheduler to use an event-driven model instead of polling Dagaen Golomb
2015-06-09 12:53 ` Dario Faggioli
2015-06-10 4:18 ` Dagaen Golomb
2015-06-10 22:30 ` Dario Faggioli
2015-06-13 20:33 ` Dagaen Golomb
2015-06-16 17:07 ` Dagaen Golomb
2015-06-17 0:20 ` Dario Faggioli
2015-06-17 5:24 ` Dagaen Golomb
2015-06-17 5:45 ` Meng Xu
2015-06-17 6:03 ` Dagaen Golomb [this message]
2015-06-17 6:09 ` Meng Xu
2015-06-17 9:20 ` Dario Faggioli
2015-06-17 8:27 ` Dario Faggioli
2015-06-18 18:07 ` Dagaen Golomb
2015-06-22 9:11 ` Dario Faggioli
2015-06-22 11:58 ` Dagaen Golomb
2015-06-10 5:54 ` Meng Xu
2015-06-10 17:46 ` Dario Faggioli
2015-06-11 5:50 ` Meng Xu
2015-06-12 9:28 ` Dario Faggioli
2015-06-13 17:21 ` 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=CALcuvTg1NNo+YU+HTCOkTKZZ4opBSAgg_ZjYk+PZk903vfoRHw@mail.gmail.com \
--to=dgolomb@seas.upenn.edu \
--cc=dario.faggioli@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=lichong659@gmail.com \
--cc=mengxu@cis.upenn.edu \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=xisisu@gmail.com \
--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).