Re: memblock vs early_res

[Jeremy Fitzhardinge <jeremy@goop.org>]

 On 09/17/2010 03:47 PM, Yinghai Lu wrote:
> On 09/17/2010 01:47 PM, Jeremy Fitzhardinge wrote:
>>  Hi Yinghai,
>>
>> I have the patch below floating around in my tree to make sure that
>> early-reserved highmem is honoured when freeing unreserved memory.  I
>> was trying to rebase it to current linux-next and noticed that all the
>> early_res stuff has been replaced with memblock.
>>
>> Is this still an issue?  What would the memblock version of this patch
>> look like?
>>
> Not sure why this patch is needed.
>
> For the early reserve ranges, that could be overlapped with high pages, is "KVA RAM",
> but We do remove those range in active ranges array. [ in calculate_numa_remap_pages() ].
> [
> ...
>                 memblock_x86_reserve_range(node_kva_final,
>                               node_kva_final+(((u64)size)<<PAGE_SHIFT),
>                               "KVA RAM");
>
>                 node_remap_start_pfn[nid] = node_kva_final>>PAGE_SHIFT;
>                 remove_active_range(nid, node_remap_start_pfn[nid],
>                                          node_remap_start_pfn[nid] + size);
> ...
> ]
>
> Can you check if Gianluca Guida still can duplicate the problem that will need his patch ?

The specific motivation for this patch is to handle Xen ballooning where
the domain can be built with X pages of memory available to it
initially, but Y pages are presented in the E820 map (Y >= X).  The
extra pages in the E820 are not physically present, but I want the
kernel to allocate page structures for them, so I reserve_early() them
to stop them from being used.  Later on, the balloon driver can
incrementally populate these pfns and return them to the kernel for use
as real memory.

Without this patch, the reservations of the highmem pages are ignored
and the kernel ends up trying to use these non-resident pages.  (At
least that's what used to happen, and I didn't see any changes which
looked like they would address this.)

Does the code you quote above address this case?

Thanks,
    J