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

["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.

Jan


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