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.029 / U:30.996 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site