[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Notes on stubdoms and latency on ARM

On Fri, 2017-05-19 at 22:45 +0300, Volodymyr Babchuk wrote:
> On 18 May 2017 at 22:00, Stefano Stabellini <sstabellini@xxxxxxxxxx>
> wrote:
> > Improve the null scheduler to enable decent stubdoms scheduling on
> > latency sensitive systems.
> I'm not very familiar with XEN schedulers. 
Feel free to ask anything. :-)

> Looks like null scheduler
> is good for hard RT, but isn't fine for a generic consumer system. 
The null scheduler is meant at being useful when you have a static
scenario, no (or very few) overbooking (i.e., total nr of vCPUs ~= nr
of pCPUS), and what to cut to _zero_ the scheduling overhead.

That may include certain class of real-time workloads, but it not
limited to such use case.

> How
> do you think: is it possible to make credit2 scheduler to schedule
> stubdoms in the same way?
It is indeed possible. Actually, it's actually in the plans to do
exactly something like that, as it could potentially be useful for a
wide range of use cases.

Doing it in the null scheduler is just easier, and we think it would be
a nice way to quickly have a proof of concept done. Afterwards, we'll
focus on other schedulers too.

> > Investigate ways to improve context switch times on ARM.
> Do you have any tools to profile or trace XEN core? Also, I don't
> think that pure context switch time is the biggest issue. Even now,
> it
> allows 180 000 switches per second (if I'm not wrong). I think,
> scheduling latency is more important.
What do you refer to when you say 'scheduling latency'? As in, the
latency between which events, happening on which component?

<<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: signature.asc
Description: This is a digitally signed message part

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.