Xen project Mailing List

Dario,

Thanks for your comments,

Here Priority will be prime Method of Sorting of VCPUs in local run queue in addition to it I am Proposing Shortest Credit First
Âwhich is similar to SJF not exactly SJF of O.S. because this is credit based.

My suggestion is Replace FCFS by SCF(Shortest Credit First) for Equal Priority VCPUs in local run-queue to reduce average waiting time spend in the queue.

SCF will be preemptive but Credit Scheduler Itself preemptive after 30 milliseconds

As per my knowledge feature haven't implemented in credit2 also

credit2 also sorts vcpus on priority and apply FCFS for equal priority .Credit2 having dynamic time slice facility instead of fix 30 milliseconds we can change 5,10,20 rest of things are as it is of credit1.

please continue commenting

Thanks

Rajendra

ÂÂ

On Tue, May 19, 2015 at 2:13 PM, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:

Hey,

First of all, can you please switch to free text email (instead than
HTML ones), and avoid top-posting?

On Tue, 2015-05-19 at 07:20 +0530, Rajendra Bele wrote:

> In O.S. it is scheduling of processes where equal priority jobs are
> always handled with FCFS.
> credit scheduler also follows same thing where equal priority VCPU s
> are scheduled with FCFS.
> In Credit Scheduler there are three priorities BOOST,UNDER,OVER
>
Correct.

> Local run queue is sorted on these priorities.
>
Sure.

> If we focus on UNDER priority ,e.g. VCPU having 512 Credits and VCPU
> having 256 credits will have same priority
> and First VCPU (512)will scheduled first and second VCPU (256) will
> have to wait though it has less credit.
>
Exactly.

> In Such scenario instead of FCFS if will follow Shortest Credit Next
> it will reduce overall average waiting time and context switch time
> hence bit enhancement in performance is possible.
>
I'm not sure how this will affect 'context switch time', but perhaps you
mean something different with it from what I have in mind (i.e., the
actual time it takes to swap two vCPUs on a physical processor).

Anyway, I think I see it now. Basically, you're proposing that we should
keep the runqueues sorted by credit, even in Credit1, and we do already
in Credit2 (at least, the idea is the same). I certainly don't disagree,
as I already said that such feature is one of the reasons I like Credit2
more than Credit1.

Which also means I certainly won't stop you from trying, but of course,
we'll have to see the patches (even in preliminary/RFC state) to
actually be able to judge how much complexity this would add; and we'll
have to see some thorough performance evaluation, to be sure it is worth
adding complexity, and that we don't introduce regressions in as many
workloads as we can imagine and check.

> In OS limitation of SJF is calculation of process time but here in
> Credit Scheduler credits are already known and computed after every 10
> milliseconds is additional advantage for implementation.
>
True. and this answer my question on how you where planning to implement
SJF. I'm not sure I'd still call the result SJF, though. In fact,
formally speaking, SJF assigns the priorities basing on the actual
runtime of a task/vCPU; here you're proposing using a configuration
parameter --which already is a form of priority, coming from the user--
as an indication of the execution time, creating a 'circle' which I'm
not sure will bring good things...

One of the possible caveat could be how Credit does load balancing
between the various pCPUs' runqueues. Right now we just steal random
pieces of work (pay attention to hard and soft affinity)... Here, you
may want to consider the credits of the vCPU(s) that you're trying to
steal.

Also, the classic SJF is non preemptive, and that is great as it makes
it simple to implement (if it only wouldn't require for you to be a
clairvoyant, it would be perfect!! :-P). Here, if you really plan to use
Credit as your approximation, well, as you said yourself, credits
changes, so you may need to look into a preemptive variant of SJF, which
is way less simple.

> The fact is definitely useful if implemented successfully
>
Yeah, _if_ :-D

> Please Pass CommentsÂ for further motivations
>
I've done my best. :-)

Regards,
Dario

Re: [Xen-devel] xen scheduler