From: ebiederm@xmission.com (Eric W. Biederman)
To: zhong jiang <zhongjiang@huawei.com>
Cc: dyoung@redhat.com, horms@verge.net.au, vgoyal@redhat.com,
yinghai@kernel.org, akpm@linux-foundation.org,
kexec@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/2] kexec: remove unnecessary unusable_pages
Date: Wed, 13 Jul 2016 00:07:18 -0500 [thread overview]
Message-ID: <87lh16unw9.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <5785BEA6.2060404@huawei.com> (zhong jiang's message of "Wed, 13 Jul 2016 12:08:06 +0800")
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
--
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>
next prev parent reply other threads:[~2016-07-13 5:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 4:56 zhongjiang
2016-07-12 4:56 ` [PATCH 2/2] kexec: add a pmd huge entry condition during the page table zhongjiang
2016-07-12 15:46 ` Eric W. Biederman
2016-07-13 7:01 ` zhong jiang
2016-07-14 13:19 ` Eric W. Biederman
2016-07-20 7:25 ` zhong jiang
2016-07-12 15:19 ` [PATCH 1/2] kexec: remove unnecessary unusable_pages Eric W. Biederman
2016-07-13 4:08 ` zhong jiang
2016-07-13 5:07 ` Eric W. Biederman [this message]
2016-07-13 7:07 ` zhong jiang
-- strict thread matches above, loose matches on Subject: below --
2016-07-11 6:36 zhongjiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lh16unw9.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=dyoung@redhat.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=vgoyal@redhat.com \
--cc=yinghai@kernel.org \
--cc=zhongjiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox