From: zhong jiang <zhongjiang@huawei.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: dyoung@redhat.com, kexec@lists.infradead.org, linux-mm@kvack.org,
horms@verge.net.au, akpm@linux-foundation.org,
yinghai@kernel.org, vgoyal@redhat.com
Subject: Re: [PATCH 1/2] kexec: remove unnecessary unusable_pages
Date: Wed, 13 Jul 2016 15:07:15 +0800 [thread overview]
Message-ID: <5785E8A3.7060109@huawei.com> (raw)
In-Reply-To: <87lh16unw9.fsf@x220.int.ebiederm.org>
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.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: zhong jiang <zhongjiang@huawei.com>
To: "Eric W. Biederman" <ebiederm@xmission.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 15:07:15 +0800 [thread overview]
Message-ID: <5785E8A3.7060109@huawei.com> (raw)
In-Reply-To: <87lh16unw9.fsf@x220.int.ebiederm.org>
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>
next prev parent reply other threads:[~2016-07-13 7:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 4:56 [PATCH 1/2] kexec: remove unnecessary unusable_pages zhongjiang
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 4:56 ` zhongjiang
2016-07-12 15:46 ` Eric W. Biederman
2016-07-12 15:46 ` Eric W. Biederman
2016-07-13 7:01 ` zhong jiang
2016-07-13 7:01 ` zhong jiang
2016-07-14 13:19 ` Eric W. Biederman
2016-07-14 13:19 ` Eric W. Biederman
2016-07-20 7:25 ` zhong jiang
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-12 15:19 ` Eric W. Biederman
2016-07-13 4:08 ` zhong jiang
2016-07-13 4:08 ` zhong jiang
2016-07-13 5:07 ` Eric W. Biederman
2016-07-13 5:07 ` Eric W. Biederman
2016-07-13 7:07 ` zhong jiang [this message]
2016-07-13 7:07 ` zhong jiang
-- strict thread matches above, loose matches on Subject: below --
2016-07-11 6:36 zhongjiang
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=5785E8A3.7060109@huawei.com \
--to=zhongjiang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=vgoyal@redhat.com \
--cc=yinghai@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.