Re: [Xen-devel] [XenRT] Cache-Aware Real-Time Xen: Partition shared cache for guest domains in Xen via page coloring

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Sun, 2015-05-10 at 22:36 -0400, Meng Xu wrote:
> Hi Dario and George,
> 
Hi Meng,

I gave a quick look at the slides. Nice work.

Although I don't have much time, I also wanted to take a quick glance at
the code, and looked it up on GitHub, where you usually host your stuff,
but couldn't find it (maybe because I'm really ignorant about how that
site works! :-P).. Is it hosted somewhere public already?

> Right now, I almost finish the first two steps and have some
> preliminary results of the real-time performance of Xen with static
> cache partition mechanism. I made a quick slide to summarize the
> current work and the future plan.
> The slide can be found at:
> http://www.cis.upenn.edu/~mengxu/cart-xen/2015-05-01-CARTXen-WiP.pdf
> 
The results look nice and promising, at least for real-time
(virtualization) workloads. I'm quite sure folks working on
embedded/automotive projects, that are looking at RTDS, would find them
very interesting (provided it works similarly well on ARM, as that's
what they use), and in fact I'm adding people from GlobalLogic to the Cc
list.

> My question is:
> Do you have any comment or concerns on the current software-based
> cache management work?
>
My first thought is the one I sort of expressed above already: do you
think it could work on ARM as well? I'm quite sure they have caches, so
the basic idea is applicable there too, but I know too few of that
architecture to see how well/bad it will behave in there! Would you have
the chance and the interest in trying to find that out? 

Another question: what are (if any) the limitations and the restrictions
we have to accept, in order to be able to take advantage of this? E.g.,
I remember someone (I think it was Andrew) mentioning that playing the
tricks you play with addresses, would make it hard/impossible to use
superpages. I also remember that you were having problems at finding
large enough chunks of contiguous memory... Are these still open issues?

> I  hope to listen to your opinions and  incorporate your opinions on
> my ongoing work instead of diverting too
> far away from Xen mainstream ideas. :-)
> 
Some more thoughts. This looks like something that could work quite well
in environment and use cases that:
 1. are rather static (i.e., no or few dynamic domain creation, well 
    defined workload inside each domain, etc.)
 2. there are not too many domains around. I mean, if you have hundreds
    of guests, it's very unlikely that you'll be able to arrange for a
    similar number of properly sized partitions, isn't it?

That is actually why I really think this could be useful for the
embedded virt people: this is exactly how their environment looks
like! :-)

I think we should definitely consider merging something that will
potentially help the emerging embedded/automotive use cases, provided
(as usual):
 1. the benefits are real and really useful (e.g., they are still there 
    on ARM)
 2. it does not disrupt other workloads, it does not impact other 
    features and it does not make the code worse (i.e., more difficult 
    to understand and to maintain)

I'd suggest, if you agree with my analysis, you try to assess 1... Maybe
GlobalLogic people could help, if they're interested.

Thanks and Regards,
Dario

Attachment: signature.asc
Description: This is a digitally signed message part

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