Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.

["H. Peter Anvin" <hpa@zytor.com>]

<zhangyanfei@cn.fujitsu.com>,"yanghy@cn.fujitsu.com" <yanghy@cn.fujitsu.com>,the arch/x86 maintainers <x86@kernel.org>,"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,Linux MM <linux-mm@kvack.org>,ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Message-ID: <aad28f9f-be10-43d8-bb98-e28d46101c44@email.android.com>

BRK makes sense as long as you can set a sane O(1) size limit.

Yinghai Lu <yinghai@kernel.org> wrote:
>[trimmed the CC list, assume too long list will not go through LKML]
>
>On Fri, Aug 23, 2013 at 9:54 AM, Zhang Yanfei
><zhangyanfei.yes@gmail.com> wrote:
>
>
>
>> By saying TJ's suggestion, you mean, we will let memblock to control
>the
>> behaviour, that said, we will do early allocations near the kernel
>image
>> range before we get the SRAT info?
>
>put the acpi override table in BRK, we still need ok from HPA.
>I have impression that he did not like it, so want to confirm from him.
>
>>
>> If so, yeah, we have been working on this direction. By doing this,
>we may
>> have two main changes:
>>
>> 1. change some of memblock's APIs to make it have the ability to
>allocate
>>    memory from low address.
>> 2. setup kernel page table down-top. Concretely, we first map the
>memory
>>    just after the kernel image to the top, then, we map 0 - kernel
>image end.
>
>how about kexec/kdump ?
>
>when load high with kexec/dump, the second kernel could be very high
>near
>TOHM.
>
>>
>> Do you guys think this is reasonable and acceptable?
>
>current boot flow that need to have all cpu and mem and pci discovered
>are not scalable.
>
>for numa system, we should boot system with cpu/mem/pci in PXM(X) only.
>and assume that PXM are not hot-removed later.
>Later during booting late stage hot add other PXM in parallel.
>
>That case, we could reduce boot time, and also could solve other PXM
>hotplug problem.
>
>Thanks
>
>Yinghai

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

--
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>