在 2019年10月01日 15:40, Baoquan He 写道: > On 09/30/19 at 05:14am, Eric W. Biederman wrote: >> Baoquan He <bhe@xxxxxxxxxx> writes: >>>> needs a little better description. I know it is not a lot on modern >>>> systems but reserving an extra 1M of memory to avoid having to special >>>> case it later seems in need of calling out. >>>> >>>> I have an old system around that I think that 640K is about 25% of >>>> memory. >>> >>> Understood. Basically 640K is wasted in this case. But we only do like >>> this in SME case, a condition checking is added. And system with SME is >>> pretty new model, it may not impact the old system. >> >> The conditional really should be based on if we are reserving memory >> for a kdump kernel. AKA if crash_kernel=XXX is specified on the kernel >> command line. >> >> At which point I think it would be very reasonable to unconditionally >> reserve the low 640k, and make the whole thing a non-issue. This would >> allow the kdump code to just not do anything special for any of the >> weird special case. >> >> It isn't perfect because we need a page or so used in the first kernel >> for bootstrapping the secondary cpus, but that seems like the least of >> evils. Especially as no one will DMA to that memory. >> >> So please let's just change what memory we reserve when crash_kernel is >> specified. > > Yes, makes sense, thanks for pointing it out. > Sorry for the delay and thanks for your comment, Eric, Baoquan and Dave Young. I will improve patch log and add the extra condition crash_kernel. I will post v2 later. Thanks. Lianbo >> >>>> How we interact with BIOS tables in the first 640k needs some >>>> explanation. Both in the first kernel and in the crash kernel. >>> >>> Yes, totally agree. >>> >>> Those BIOS tables have been reserved as e820 reserved regions and will >>> be passed to kdump kernel for reusing. Memblock reserved 640K doesn't >>> mean it will cover the whole [0, 640K) region, it only searches for >>> available system RAM from memblock allocator. >> >> Careful with that assumption. My memory is that the e820 memory map >> frequently fails to cover areas like the real mode interrupt descriptor >> table at address 0. > > OK, will think more about this. Thanks. > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
