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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.15 at 16:27, <xumengpanda@xxxxxxxxx> wrote:
> 2015-01-14 10:02 GMT-05:00 Jan Beulich <JBeulich@xxxxxxxx>:
>>>>> On 14.01.15 at 15:45, <xumengpanda@xxxxxxxxx> wrote:
>>> Yes. I try to use the bits [A16, A12] to isolate different colors in a
>>> shared cache. A 2MB 16-way associate shared cache uses [A16, A6] to
>>> index the cache set. Because page size is 4KB, we have page frame
>>> number's bits [A16, A12] overlapped with the bits used to index a
>>> shared cache's cache set. So we can control those [A16, A12] bits to
>>> control where the page should be placed. (The wiki pages about page
>>> coloring is here: http://en.wikipedia.org/wiki/Cache_coloring)
>>
>> But the majority of allocations done for guests would be as 2M or
>> 1G pages,
> 
> First, I want to confirm my understanding is not incorrect: When Xen
> allocate memory pages to guests, it current allocate a bunch of memory
> pages at one time to guests. That's why you said the majority
> allocation would be 2MB or 1GB. But the size of one memory page used
> by guests is still 4KB. Am I correct?

Yes.

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

> I find in arch_setup_meminit() function in tools/libxc/xc_dom_x86.c
> allocate memory pages depending on if the dom->superpages is true.
> Can we add a if-else to allocate one page at each time to the guest
> instead of allocate many pages in one time?

That's for PV guests, which (by default) can't use 2M (not to speak of
1G) pages anyway.

Jan


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