[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
    Fix linux-arm-kernel address.

    On Fri, Jan 21, 2011 at 2:43 AM, Minchan Kim <> wrote:
    > 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. :)
    > Thanks.
    > --
    > Kind regards,
    > Minchan Kim

    Kind regards,
    Minchan Kim

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