Re: Notes on stubdoms and latency on ARM

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1935 bytes --]

On Fri, 2017-05-19 at 22:45 +0300, Volodymyr Babchuk wrote:
> On 18 May 2017 at 22:00, Stefano Stabellini <sstabellini@kernel.org>
> wrote:
> > ACTIONS:
> > 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?

Regards,
Dario
-- 
<<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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel