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. Thanks, -Toshi -- 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>