Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU

["H. Peter Anvin" <hpa@zytor.com>]

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.