Re: ARM - why does setup_frametable_size() round frametable_size to 32MB ?

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-07-17 at 21:19 +0000, Chris (Christopher) Brand wrote:
> Hi,
> 
> I'm working on a platform with a mere 2GB of RAM, and trying to
> trim the Xen footprint down as much as possible. I've found two
> places where Xen uses more memory than it seems it needs to,
> one of which is the frametable. On a 2GB system, frametable_size
> is initially calculated as 16MB, but is then rounded up to 32MB.
> can somebody tell me why this is done, and therefore whether
> it can be avoided ? I assume it's because the code then calls
> create_32mb_mappings(), in which case I guess my question
> is what's special about 32MB ?

It's 16 lots of 2MB, so we can use the contiguous hint in the PTE entry
(which saves on TLB space or whatever).

It would be fine to not use that for a sub-32MB sized mappings. I think
if the size is <32MB we should just round to a 2MB boundary (since we do
still want to use super pages) and map those without the contig bit.

I suppose for things which are >32MB we may as well keep rounding to
32MB, rather than creating N-1 32MB contiguous mappings and a bunch of
non-contiguous ones for the slop at the end.

Perhaps there is no harm in creating a 32MB mapping of a smaller region,
I suppose it depends on how the corner cases like e.g. that mapping
crossing into an MMIO region is handled. It's probably not worth the
hassle to find out...

Ian.


> 
>     unsigned long frametable_size = nr_pdxs * sizeof(struct page_info);
> [...]
>     /* Round up to 32M boundary */
>     frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
> 
> Thanks,
> 
> Chris
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel