lkml.org 
[lkml]   [2012]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2012-12-15 23:21    [W:0.182 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site