Re: [Xen-devel] Question about partitioning shared cache in Xen

[Meng Xu <xumengpanda@xxxxxxxxx>]

2015-01-15 3:23 GMT-05:00 Jan Beulich <JBeulich@xxxxxxxx>:
>>>> On 14.01.15 at 22:19, <xumengpanda@xxxxxxxxx> wrote:
>> So when Xen allocate memory to a PV guest with 256MB memory and 4KB
>> page size (i.e., 2^16 memory pages), Xen will allocate 2^16 continuous
>> memory pages to this guest since the maximum continuous memory pages
>> Xen allocates to PV guest is 1024*1024.
>
> Provided this is (a) not a debug build and (b) there is a large enough
> chunk of memory available.
>
>> Although the 2^16 memory pages are continuous, Xen still need to fill
>> this guest's p2m table in a page-by-page fashion, which means each
>> element in the guest's p2m table is the page frame number of one 4KB
>> page. Right?
>
> Sure, but again only for PV.
>
>>>> But can we allocate one memory page to guests until the guests have
>>>> enough pages?
>>>
>>> We can, but that's inefficient for TLB usage and page table lookup.
>>
>> IMHO, that's true for any case when we have a smaller page size. In my
>> understanding, Xen manages guests' memory, say p2m table or m2p table,
>> in the granularity of 4KB page. In other words, the page size in Xen
>> is still 4KB. (Please correct me if I'm wrong.)
>
> Once again - correct for PV (without the [unsupported?] superpages
> flag set), but not for PVH/HVM.
>
>> So if the number of pages a guest requests does not change, (which
>> means the size of page is 4KB,) the TLB usage should be same.
>> If the page size in Xen is larger than 4KB, the TLB usage will
>> increase for sure if we force Xen to use 4KB page size.
>
> And that's what is the case for PVH/HVM.
>
>> OK. Suppose TLB usage and page table lookup becomes inefficient
>> because of the page coloring mechanism. I totally agree that
>> non-continuous memory may hurt the performance of a guest when the
>> guest runs alone. However, the shared-cache partition can make the
>> performance of a guest more stable and not easy to be influenced by
>> other guests. Briefly speaking, I'm trying to make the running time of
>> the workload in a guest more deterministic and robust to other guests'
>> interference.
>>
>> For those application, like the control program in automobile, that
>> must produce results within a deadline, a deterministic execution time
>> is more important than an execution time that is smaller in most cases
>> but may be very large in worst case.
>
> Understood, but in that case I suppose this may need to be a
> default-off optional feature.
>

Yes. Actually, right now I just want to evaluate if the idea of shared
cache partition works on Xen in some specific applications. People did
such similar things in Linux (in the research projects) and according
to wiki (http://en.wikipedia.org/wiki/Cache_coloring), some OS, e.g.,
FreeBSD, supports it. So I'm curious about the performance of the page
coloring mechanism on Xen and the strength and weakness of it.
(Although in theory, we know the strength and weakness, I want/hope to
see it in practical implementation. That's why I'm trying to do this.)

Thank you very much for your explanation and confirmation of my
understanding! :-)

Best,

Meng




-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

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