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 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.