lkml.org 
[lkml]   [2018]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 1/2] mm: Move page struct poisoning from CONFIG_DEBUG_VM to CONFIG_DEBUG_VM_PGFLAGS
    Date
    Hi Alexander,

    This is a wrong way to do it. memblock_virt_alloc_try_nid_raw() does not
    initialize allocated memory, and by setting memory to all ones in debug
    build we ensure that no callers rely on this function to return zeroed
    memory just by accident.

    And, the accidents are frequent because most of the BIOSes and
    hypervisors zero memory for us. The exception is kexec reboot.

    So, the fact that page flags checks this pattern, does not mean that
    this is the only user. Memory that is returned by
    memblock_virt_alloc_try_nid_raw() is used for page table as well, and
    can be used in other places as well that don't want memblock to zero the
    memory for them for performance reasons.

    I am surprised that CONFIG_DEBUG_VM is used in production kernel, but if
    so perhaps a new CONFIG should be added: CONFIG_DEBUG_MEMBLOCK

    Thank you,
    Pavel

    On 9/4/18 2:33 PM, Alexander Duyck wrote:
    > From: Alexander Duyck <alexander.h.duyck@intel.com>
    >
    > On systems with a large amount of memory it can take a significant amount
    > of time to initialize all of the page structs with the PAGE_POISON_PATTERN
    > value. I have seen it take over 2 minutes to initialize a system with
    > over 12GB of RAM.
    >
    > In order to work around the issue I had to disable CONFIG_DEBUG_VM and then
    > the boot time returned to something much more reasonable as the
    > arch_add_memory call completed in milliseconds versus seconds. However in
    > doing that I had to disable all of the other VM debugging on the system.
    >
    > I did a bit of research and it seems like the only function that checks
    > for this poison value is the PagePoisoned function, and it is only called
    > in two spots. One is the PF_POISONED_CHECK macro that is only in use when
    > CONFIG_DEBUG_VM_PGFLAGS is defined, and the other is as a part of the
    > __dump_page function which is using the check to prevent a recursive
    > failure in the event of discovering a poisoned page.
    >
    > With this being the case I am opting to move the poisoning of the page
    > structs from CONFIG_DEBUG_VM to CONFIG_DEBUG_VM_PGFLAGS so that we are
    > only performing the memset if it will be used to test for failures.
    >
    > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
    > ---
    > mm/memblock.c | 2 +-
    > mm/sparse.c | 2 +-
    > 2 files changed, 2 insertions(+), 2 deletions(-)
    >
    > diff --git a/mm/memblock.c b/mm/memblock.c
    > index 237944479d25..51e8ae927257 100644
    > --- a/mm/memblock.c
    > +++ b/mm/memblock.c
    > @@ -1444,7 +1444,7 @@ void * __init memblock_virt_alloc_try_nid_raw(
    >
    > ptr = memblock_virt_alloc_internal(size, align,
    > min_addr, max_addr, nid);
    > -#ifdef CONFIG_DEBUG_VM
    > +#ifdef CONFIG_DEBUG_VM_PGFLAGS
    > if (ptr && size > 0)
    > memset(ptr, PAGE_POISON_PATTERN, size);
    > #endif
    > diff --git a/mm/sparse.c b/mm/sparse.c
    > index 10b07eea9a6e..0fd9ad5021b0 100644
    > --- a/mm/sparse.c
    > +++ b/mm/sparse.c
    > @@ -696,7 +696,7 @@ int __meminit sparse_add_one_section(struct pglist_data *pgdat,
    > goto out;
    > }
    >
    > -#ifdef CONFIG_DEBUG_VM
    > +#ifdef CONFIG_DEBUG_VM_PGFLAGS
    > /*
    > * Poison uninitialized struct pages in order to catch invalid flags
    > * combinations.
    >
    \
     
     \ /
      Last update: 2018-09-04 22:07    [W:3.317 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site