[PATCH 1/2] kexec: remove unnecessary unusable_pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



zhong jiang <zhongjiang at huawei.com> writes:

> On 2016/7/12 23:19, Eric W. Biederman wrote:
>> zhongjiang <zhongjiang at huawei.com> writes:
>>
>>> From: zhong jiang <zhongjiang at 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 at 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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux