Messages in this thread | | | Date | Sat, 15 Dec 2012 13:40:25 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU |
| |
On 12/15/2012 12:55 PM, Yinghai Lu wrote: > On Sat, Dec 15, 2012 at 11:30 AM, H. Peter Anvin <hpa@linux.intel.com> 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. >
In other words, you make magic assumptions (some of which are very wrong in many real-life scenarios -- people can and do use gigabyte-plus initramfs). That is exactly the wrong thing to do. Furthermore it doesn't buy you anything, because you still have to allocate the PMDs.
> Also if we set map too large, could have chance to cover mem hole near > 1T for AMD HT system.
Again, should not be cachable in the MTRRs, and even so, is 1G aligned already.
>> 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 you consider that panic an acceptable failure mode????
> and current BRK already have 64 slop space. > > BTW, did you look at smp boot problem with early_level4_pgt version?
No, I have been busy with non-Linux stuff today.
-hpa
-- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
| |