From: Meng Xu <xumengpanda@gmail.com>
To: Dagaen Golomb <dgolomb@seas.upenn.edu>
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: Tue, 16 Jun 2015 22:45:29 -0700 [thread overview]
Message-ID: <CAENZ-+nfN6qm7XmQSnWns1FYjKNqEdZBkJFViCYaxMRSaBp0hw@mail.gmail.com> (raw)
In-Reply-To: <CALcuvTiaw3OuhFVfwka-bJGbsG0r1cY2Lxu8dLTmZD1Xmu-L7g@mail.gmail.com>
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/
next prev parent reply other threads:[~2015-06-17 5:45 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 [this message]
2015-06-17 6:03 ` Dagaen Golomb
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=CAENZ-+nfN6qm7XmQSnWns1FYjKNqEdZBkJFViCYaxMRSaBp0hw@mail.gmail.com \
--to=xumengpanda@gmail.com \
--cc=dario.faggioli@citrix.com \
--cc=dgolomb@seas.upenn.edu \
--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 \
/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.