The mem hole at 1T should not be marked cachable in the MTRRs. Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >On Sat, Dec 15, 2012 at 11:30 AM, H. Peter Anvin <hpa@xxxxxxxxxxxxxxx> >wrote: >> What is the point of only managing 2M at a time? Now you have to >have >> more conditionals and you don't get any more memory efficiency. > >We don't need to, because real_data is less than 2M, and ramdisk is >about 16M. > >Also if we set map too large, could have chance to cover mem hole near >1T for AMD HT system. > >> >> Filling arbitrarily into the brk is not acceptable... the brk is an >O(1) >> area and all brk allocations need to be reserved at compile time, so >the >> overflow handling is still necessary. > >if run out of BRK, we will get panic, because early_make_pgtable will >return -1. > >and current BRK already have 64 slop space. > >BTW, did you look at smp boot problem with early_level4_pgt version? > >Yinghai -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html