lkml.org 
[lkml]   [2011]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: questions about init_memory_mapping_high()
On 02/23/2011 12:46 PM, Tejun Heo wrote:
> On Wed, Feb 23, 2011 at 12:24:58PM -0800, Yinghai Lu wrote:
>>> I guess this was the reason why the commit message showed usage of
>>> 2MiB mappings so that each node would end up with their own third
>>> level page tables. Is this something we need to optimize for? I
>>> don't recall seeing recent machines which don't use 1GiB pages for
>>> the linear mapping. Are there NUMA machines which can't use 1GiB
>>> mappings?
>>
>> till now:
>> amd 64 cpu does support 1gb page.
>>
>> Intel CPU Nehalem-EX does not. and several vendors do provide 8 sockets
>> NUMA system with 1024g and 2048g RAM
>
> That's interesting. Didn't expect that. So, this one is an actually
> valid reason for implementing per node mapping. Is this Nehalem-EX
> only thing? Or is it applicable to all xeons upto now?

only have access for Nehalem-EX and Westmere-EX till now.

>
>>> 3. The new code creates linear mapping only for memory regions where
>>> e820 actually says there is memory as opposed to mapping from base
>>> to top. Again, I'm not sure what the intention of this change was.
>>> Having larger mappings over holes is much cheaper than having to
>>> break down the mappings into smaller sized mappings around the
>>> holes both in terms of memory and run time overhead. Why would we
>>> want to match the linear address mapping to the e820 map exactly?
>>
>> we don't need to map those holes if there is any.
>
> Yeah, sure, my point was that not mapping those holes is likely to be
> worse. Wouldn't it be better to get low and high ends of the occupied
> area and expand those to larger mapping size? It's worse to match the
> memory map exactly. You unnecessarily end up with smaller mappings.

it will reuse previous not used entries in the init_memory_mapping().

>
>> for hotplug case, they should map new added memory later.
>
> Sure.
>
>>> Also, Yinghai, can you please try to write commit descriptions with
>>> more details? It really sucks for other people when they have to
>>> guess what the actual changes and underlying intentions are. The
>>> commit adding init_memory_mapping_high() is very anemic on details
>>> about how the behavior changes and the only intention given there is
>>> RED-PEN removal even which is largely a miss.
>>
>> i don't know what you are talking about. that changelog is clear enough.
>
> Ah well, if you still think the changelog is clear enough, I give up.
> I guess I'll just keep rewriting your changelogs.

Thank you very much.

Yinghai


\
 
 \ /
  Last update: 2011-02-23 21:55    [W:0.061 / U:0.504 seconds]
©2003-2014 Jasper Spaans. Advertise on this site