On Thu, Aug 15, 2013 at 12:06 PM, Toshi Kani <toshi.kani@xxxxxx> wrote: > On Wed, 2013-08-14 at 09:22 +0800, Tang Chen wrote: >> On 08/14/2013 06:33 AM, Yinghai Lu wrote: >> ...... >> > >> >> relocate_initrd() >> > >> > size could be very big, like several hundreds mega bytes. >> > should be anywhere, but will be freed after booting. >> > >> > ===> so we should not limit it to near kernel range. >> > >> >> acpi_initrd_override() >> > >> > should be 64 * 10 about 1M. >> > >> >> reserve_crashkernel() >> > >> > could be under 4G, or above 4G. >> > size could be 512M or 8G whatever. >> > >> > looks like >> > should move down relocated_initrd and reserve_crashkernel. >> >> OK, will try to do this. >> >> Thank you for the explanation. :) > > So, we still need reordering, and put a new requirement that all earlier > allocations must be small... > > I think the root of this issue is that ACPI init point is not early > enough in the boot sequence. If it were much earlier already, the whole > thing would have been very simple. We are now trying to workaround this > issue in the mblock code (which itself is a fine idea), but this ACPI > issue still remains and similar issues may come up again in future. > > For instance, ACPI SCPR/DBGP/DBG2 tables allow the OS to initialize > serial console/debug ports at early boot time. The earlier it can be > initialized, the better this feature will be. These tables are not > currently used by Linux due to a licensing issue, but it could be > addressed some time soon. As platforms becoming more complex & legacy > free, the needs of ACPI tables will increase. > > I think moving up the ACPI init point earlier is a good direction. Good point. If we put acpi_initrd_override in BRK, and can more acpi_boot_table_init() much early. Yinghai -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>