Re: [PATCH 1/2] kexec: remove unnecessary unusable_pages

[zhong jiang <zhongjiang@huawei.com>]

On 2016/7/13 13:07, Eric W. Biederman wrote:
> zhong jiang <zhongjiang@huawei.com> writes:
>
>> On 2016/7/12 23:19, Eric W. Biederman wrote:
>>> zhongjiang <zhongjiang@huawei.com> writes:
>>>
>>>> From: zhong jiang <zhongjiang@huawei.com>
>>>>
>>>> In general, kexec alloc pages from buddy system, it cannot exceed
>>>> the physical address in the system.
>>>>
>>>> The patch just remove this unnecessary code, no functional change.
>>> On 32bit systems with highmem support kexec can very easily receive a
>>> page from the buddy allocator that can exceed 4GiB.  This doesn't show
>>> up on 64bit systems as typically the memory limits are less than the
>>> address space.  But this code is very necessary on some systems and
>>> removing it is not ok.
>>>
>>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>>
>>   This viewpoint is as opposed to me,  32bit systems architectural decide it can not
>>   access exceed 4GiB whether the highmem or not.   but there is one exception, 
>>   when PAE enable, its physical address should be extended to 36,  new paging  mechanism
>>   established for it.  therefore, the  page from the buddy allocator
>>   can exceed 4GiB.
> Exactly.  And I was dealing with PAE systems in 2001 or so with > 4GiB
> of RAM.  Which is where the unusable_pages work comes from.
>
> Other architectures such as ARM also followed a similar path, so
> it isn't just x86 that has 32bit systems with > 32 address lines.
>
>>   moreover,  on 32bit systems I can not understand why KEXEC_SOURCE_MEMORY_LIMIT
>>   is defined to -1UL. therefore, kimge_aloc_page allocate page will always add to unusable_pages.
> -1UL is a short way of writing 0xffffffffUL  Which is as close as you
> can get to writing 0x100000000UL in 32bits.
>
> kimage_alloc_page won't always add to unusable_pages as there is memory
> below 4GiB but it isn't easily found so there may temporarily be a
> memory shortage, as it allocates it's way there.  Unfortunately whenever
> I have looked there are memory zones that line up with the memory the
> kexec is looking for.  So it does a little bit of a weird dance to get
> the memory it needs and to discard the memory it can't use.
>
> Eric
>
  Thanks , I get it.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>