[lkml]   [2011]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] ARM: mm: Regarding section when dealing with meminfo
    Restore Cced.

    On Fri, Jan 21, 2011 at 2:24 AM, KyongHo Cho <> wrote:
    > On Thu, Jan 20, 2011 at 11:28 PM, Minchan Kim <> wrote:
    >> On Thu, Jan 20, 2011 at 06:45:39PM +0900, KyongHo Cho wrote:
    >>> Sparsemem allows that a bank of memory spans over several adjacent
    >>> sections if the start address and the end address of the bank
    >>> belong to different sections.
    >>> When gathering statictics of physical memory in mem_init() and
    >>> show_mem(), this possiblity was not considered.
    >> Please write down the result if we doesn't consider this patch.
    >> I can understand what happens but for making good description and review,
    >> merging easily, it would be better to write down the result without
    >> the patch explicitly.
    > As we know that each section has its own memmap and
    > a contiguous chunk of physical memory that is represented by 'bank' in meminfo
    > can be larger than the size of a section.
    > "page++" in the current implementation can access invalid memory area.
    > The size of the section is 256 MiB in ARM and the number of banks in
    > meminfo is 8.
    > This means that the maximum size of the physical memory cannot be grow than 2GiB
    > to avoid this problem in the current implementation.
    > Thus we need to fix the calculation of the last page descriptor in
    > terms of sections.
    > This patch determines the last page descriptor in a memmap with
    > min(last_pfn_of_bank, last_pfn_of_current_section)
    > If there remains physical memory not consumed, it calculates the last
    > page descriptor
    > with min(last_pfn_of_bank, last_pfn_of_next_section).
    >> Hmm.. new ifndef magic makes code readability bad.
    >> Couldn't we do it by simple pfn iterator not page and pfn_valid check?
    > True.
    > We need to consider the implementation again.
    > I think the previous implementation gave the importance to the
    > efficiency but to the readability.

    Please consider readability and consistency with other architectures
    if we can do. :)

    Kind regards,
    Minchan Kim

     \ /
      Last update: 2011-01-20 18:45    [W:0.022 / U:6.432 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site