linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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