|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and heap allocator
On Wed, 31 Aug 2022, Henry Wang wrote:
> > -----Original Message-----
> > From: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > > and we can automatically calculate xenheap_pages in a single line.
> > >
> > > Here I am a little bit confused. Sorry to ask but could you please explain
> > > a little bit more about why we can calculate the xenheap_pages in a single
> > > line? Below is the code snippet in my mind, is this correct?
> > >
> > > if (reserved_heap)
> >
> > coding style
> >
> > > e = reserved_heap_end;
> > > else
> > > {
> > > do
> > > {
> > > e = consider_modules(ram_start, ram_end,
> > > pfn_to_paddr(xenheap_pages),
> > > 32<<20, 0);
> > > if ( e )
> > > break;
> > >
> > > xenheap_pages >>= 1;
> > > } while ( !opt_xenheap_megabytes && xenheap_pages > 32<<(20-
> > PAGE_SHIFT) );
> > > }
> >
> > Yes, this is what I meant.
>
> Thank you very much for your detailed explanation below!
> [...]
>
> >
> > But also, here the loop is also for adjusting xenheap_pages, and
> > xenheap_pages is initialized as follows:
> >
> >
> > if ( opt_xenheap_megabytes )
> > xenheap_pages = opt_xenheap_megabytes << (20-PAGE_SHIFT);
> > else
> > {
> > xenheap_pages = (heap_pages/32 + 0x1fffUL) & ~0x1fffUL;
> > xenheap_pages = max(xenheap_pages, 32UL<<(20-PAGE_SHIFT));
> > xenheap_pages = min(xenheap_pages, 1UL<<(30-PAGE_SHIFT));
> > }
> >
> >
> > In the reserved_heap case, it doesn't make sense to initialize
> > xenheap_pages like that, right? It should be something like:
>
> I am not sure about that, since we already have
> heap_pages = reserved_heap ? reserved_heap_pages : ram_pages;
>
> the heap_pages is supposed to contain domheap_pages + xenheap_pages
> based on the reserved heap definition discussed in the RFC.
>
> from the code in...
>
> >
> > if ( opt_xenheap_megabytes )
> > xenheap_pages = opt_xenheap_megabytes << (20-PAGE_SHIFT);
> > else if ( reserved_heap )
> > xenheap_pages = heap_pages;
>
> ...here, setting xenheap_pages to heap_pages makes me a little bit
> confused.
>
> > else
> > {
> > xenheap_pages = (heap_pages/32 + 0x1fffUL) & ~0x1fffUL;
> > xenheap_pages = max(xenheap_pages, 32UL<<(20-PAGE_SHIFT));
> > xenheap_pages = min(xenheap_pages, 1UL<<(30-PAGE_SHIFT));
> > }
>
> If we keep this logic as this patch does, we can have the requirements...
>
> >
> > But also it looks like that on arm32 we have specific requirements for
> > Xen heap:
> >
> > * - must be 32 MiB aligned
> > * - must not include Xen itself or the boot modules
> > * - must be at most 1GB or 1/32 the total RAM in the system if less
> > * - must be at least 32M
>
> ...here, with the "1/32 the total RAM" now being "1/32 of the total reserved
> heap region", since heap_pages is now reserved_heap_pages.
I see. I didn't realize the full implications of the memory being used
for both xenheap and domheap on arm32. In that case, I would simply do
the following:
heap_pages = !reserved_heap ? ram_pages : reserved_heap_pages;
if ( opt_xenheap_megabytes )
xenheap_pages = opt_xenheap_megabytes << (20-PAGE_SHIFT);
else
{
xenheap_pages = (heap_pages/32 + 0x1fffUL) & ~0x1fffUL;
xenheap_pages = max(xenheap_pages, 32UL<<(20-PAGE_SHIFT));
xenheap_pages = min(xenheap_pages, 1UL<<(30-PAGE_SHIFT));
}
if ( reserved_heap )
e = reserved_heap_end;
else
{
do
{
e = consider_modules(ram_start, ram_end,
pfn_to_paddr(xenheap_pages),
32<<20, 0);
if ( e )
break;
xenheap_pages >>= 1;
} while ( !opt_xenheap_megabytes && xenheap_pages > 32<<(20-PAGE_SHIFT)
);
}
if ( ! e ||
( reserved_heap && reserved_heap_pages < 32<<(20-PAGE_SHIFT) ) )
panic("Not enough space for xenheap\n");
domheap_pages = heap_pages - xenheap_pages;
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |