From: Prarit Bhargava <prarit@redhat.com>
To: Toshi Kani <toshi.kani@hp.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
Bodo Eggert <7eggert@gmx.de>, LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
the arch/x86 maintainers <x86@kernel.org>,
Len Brown <lenb@kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linn Crosetto <linn@hp.com>, Pekka Enberg <penberg@kernel.org>,
Yinghai Lu <yinghai@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tang Chen <tangchen@cn.fujitsu.com>,
Wen Congyang <wency@cn.fujitsu.com>,
Vivek Goyal <vgoyal@redhat.com>,
dyoung@redhat.com, linux-acpi@vger.kernel.org,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 2/2] x86, e820 disable ACPI Memory Hotplug if memory mapping is specified by user [v2]
Date: Tue, 14 Jan 2014 06:02:16 -0500 [thread overview]
Message-ID: <52D51938.1090408@redhat.com> (raw)
In-Reply-To: <1389659632.1792.247.camel@misato.fc.hp.com>
On 01/13/2014 07:33 PM, Toshi Kani wrote:
> On Mon, 2014-01-13 at 18:39 -0500, Prarit Bhargava wrote:
>>
>> On 01/13/2014 03:31 PM, KOSAKI Motohiro wrote:
>>> On Sun, Jan 12, 2014 at 6:46 PM, Prarit Bhargava <prarit@redhat.com> wrote:
>>>>
>>>>
>>>> On 01/11/2014 11:35 AM, 7eggert@gmx.de wrote:
>>>>>
>>>>>
>>>>> On Fri, 10 Jan 2014, Prarit Bhargava wrote:
>>>>>
>>>>>> kdump uses memmap=exactmap and mem=X values to configure the memory
>>>>>> mapping for the kdump kernel. If memory is hotadded during the boot of
>>>>>> the kdump kernel it is possible that the page tables for the new memory
>>>>>> cause the kdump kernel to run out of memory.
>>>>>>
>>>>>> Since the user has specified a specific mapping ACPI Memory Hotplug should be
>>>>>> disabled in this case.
>>>>>
>>>>> I'll ask just in case: Is it possible to want memory hotplug in spite of
>>>>> using memmap=exactmap or mem=X?
>>>>
>>>> Good question -- I can't think of a case. When a user specifies "memmap" or
>>>> "mem" IMO they are asking for a very specific memory configuration. Having
>>>> extra memory added above what the user has specified seems to defeat the purpose
>>>> of "memmap" and "mem".
>>>
>>> May be yes, may be no.
>>>
>>> They are often used for a wrokaround to avoid broken firmware issue.
>>> If we have no way
>>> to explicitly enable hotplug. We will lose a workaround.
>>>
>>> Perhaps, there is no matter. Today, memory hotplug is only used on
>>> high-end machine
>>> and their firmware is carefully developped and don't have a serious
>>> issue almostly. Though.
>>
>> Oof -- sorry Kosaki :( I didn't see this until just now (and your subsequent
>> ACK on the updated patch).
>>
>> I just remembered that we did have a processor vendor's whitebox that would not
>> boot unless we specified a specific memmap and we did specify memmap=exactmap to
>> boot the system correctly and the system had hotplug memory.
>>
>> So it means that I should not key off of "memmap=exactmap".
>
> I do not think it makes sense. You needed memmap=exactmap as a
> workaround because the kernel did not boot with the firmware's memory
> info. So, it's broken, and you requested the kernel to ignore the
> firmware info.
>
> Why do you think memory hotplug needs to be supported under such
> condition, which has to use the broken firmware info?
There was a memory address region that was not in the e820 map that had to be
reserved for a specific device's use. It was not so we used memmap=exactmap and
other memmap entries to "rewrite" the e820 map to see if the system would boot;
then I filed a bug against the hardware vendor ;)
So, yes, in that case I did want memory hotplug & memmap=exactmap. Admittedly
this was a rare corner case, and I certainly could have recompiled the kernel.
P.
>
> Thanks,
> -Toshi
>
>
>
--
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>
prev parent reply other threads:[~2014-01-14 11:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-10 19:04 [PATCH 0/2] Add option to disable ACPI Memory Hotplug [v2] Prarit Bhargava
2014-01-10 19:04 ` [PATCH 0/2] Add option to disable ACPI Memory Hotplug Prarit Bhargava
2014-01-10 19:04 ` [PATCH 1/2] acpi memory hotplug, add parameter to disable memory hotplug [v2] Prarit Bhargava
2014-01-10 21:34 ` Toshi Kani
2014-01-10 19:04 ` [PATCH 2/2] x86, e820 disable ACPI Memory Hotplug if memory mapping is specified by user [v2] Prarit Bhargava
2014-01-10 21:12 ` Vivek Goyal
2014-01-10 21:34 ` Toshi Kani
2014-01-11 16:35 ` 7eggert
2014-01-12 23:46 ` Prarit Bhargava
2014-01-13 20:31 ` KOSAKI Motohiro
2014-01-13 23:39 ` Prarit Bhargava
2014-01-14 0:33 ` Toshi Kani
2014-01-14 0:53 ` H. Peter Anvin
2014-01-14 1:09 ` Toshi Kani
2014-01-14 1:29 ` H. Peter Anvin
2014-01-14 1:40 ` Toshi Kani
2014-01-14 1:52 ` Dave Young
2014-01-14 1:47 ` Toshi Kani
2014-01-14 11:02 ` Prarit Bhargava [this message]
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=52D51938.1090408@redhat.com \
--to=prarit@redhat.com \
--cc=7eggert@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=kosaki.motohiro@gmail.com \
--cc=lenb@kernel.org \
--cc=linn@hp.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=penberg@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tangchen@cn.fujitsu.com \
--cc=tglx@linutronix.de \
--cc=toshi.kani@hp.com \
--cc=vgoyal@redhat.com \
--cc=wency@cn.fujitsu.com \
--cc=x86@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox