From: Dan Williams <dan.j.williams@intel.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: pavel.tatashin@microsoft.com, "Michal Hocko" <mhocko@suse.com>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
"Dave Hansen" <dave.hansen@intel.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Linux MM" <linux-mm@kvack.org>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Ingo Molnar" <mingo@kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning
Date: Tue, 11 Sep 2018 09:50:57 -0700 [thread overview]
Message-ID: <CAPcyv4j301Ma8D65oMzFo9-jVdwKGHzOVHb=7u9XaxACR5RAhg@mail.gmail.com> (raw)
In-Reply-To: <20180910234341.4068.26882.stgit@localhost.localdomain>
On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck
<alexander.duyck@gmail.com> 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.
>
> In order to work around a kernel that might have CONFIG_DEBUG_VM enabled on
> a system that has a large amount of memory I have added a new kernel
> parameter named "page_init_poison" that can be set to "off" in order to
> disable it.
In anticipation of potentially more DEBUG_VM options wanting runtime
control I'd propose creating a new "vm_debug=" option for this modeled
after "slub_debug=" along with a CONFIG_DEBUG_VM_ON to turn on all
options.
That way there is more differentiation for debug cases like this that
have significant performance impact when enabled.
CONFIG_DEBUG_VM leaves optional debug capabilities disabled by default
unless CONFIG_DEBUG_VM_ON is also set.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: "Linux MM" <linux-mm@kvack.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
pavel.tatashin@microsoft.com, "Michal Hocko" <mhocko@suse.com>,
"Dave Jiang" <dave.jiang@intel.com>,
"Ingo Molnar" <mingo@kernel.org>,
"Dave Hansen" <dave.hansen@intel.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Logan Gunthorpe" <logang@deltatee.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning
Date: Tue, 11 Sep 2018 09:50:57 -0700 [thread overview]
Message-ID: <CAPcyv4j301Ma8D65oMzFo9-jVdwKGHzOVHb=7u9XaxACR5RAhg@mail.gmail.com> (raw)
In-Reply-To: <20180910234341.4068.26882.stgit@localhost.localdomain>
On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck
<alexander.duyck@gmail.com> 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.
>
> In order to work around a kernel that might have CONFIG_DEBUG_VM enabled on
> a system that has a large amount of memory I have added a new kernel
> parameter named "page_init_poison" that can be set to "off" in order to
> disable it.
In anticipation of potentially more DEBUG_VM options wanting runtime
control I'd propose creating a new "vm_debug=" option for this modeled
after "slub_debug=" along with a CONFIG_DEBUG_VM_ON to turn on all
options.
That way there is more differentiation for debug cases like this that
have significant performance impact when enabled.
CONFIG_DEBUG_VM leaves optional debug capabilities disabled by default
unless CONFIG_DEBUG_VM_ON is also set.
next prev parent reply other threads:[~2018-09-11 16:50 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-10 23:43 [PATCH 0/4] Address issues slowing persistent memory initialization Alexander Duyck
2018-09-10 23:43 ` Alexander Duyck
2018-09-10 23:43 ` [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning Alexander Duyck
2018-09-10 23:43 ` Alexander Duyck
2018-09-11 0:35 ` Alexander Duyck
2018-09-11 0:35 ` Alexander Duyck
2018-09-11 16:50 ` Dan Williams [this message]
2018-09-11 16:50 ` Dan Williams
2018-09-11 20:01 ` Alexander Duyck
2018-09-11 20:01 ` Alexander Duyck
2018-09-11 20:24 ` Dan Williams
2018-09-11 20:24 ` Dan Williams
2018-09-12 13:24 ` Pasha Tatashin
2018-09-12 14:10 ` Michal Hocko
2018-09-12 14:10 ` Michal Hocko
2018-09-12 14:49 ` Alexander Duyck
2018-09-12 14:49 ` Alexander Duyck
2018-09-12 15:23 ` Dave Hansen
2018-09-12 15:23 ` Dave Hansen
2018-09-12 16:36 ` Alexander Duyck
2018-09-12 16:43 ` Dave Hansen
2018-09-12 16:43 ` Dave Hansen
2018-09-10 23:43 ` [PATCH 2/4] mm: Create non-atomic version of SetPageReserved for init use Alexander Duyck
2018-09-10 23:43 ` Alexander Duyck
2018-09-12 13:28 ` Pasha Tatashin
2018-09-10 23:43 ` [PATCH 3/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap Alexander Duyck
2018-09-10 23:43 ` Alexander Duyck
2018-09-11 7:49 ` kbuild test robot
2018-09-11 7:49 ` kbuild test robot
2018-09-11 7:54 ` kbuild test robot
2018-09-11 7:54 ` kbuild test robot
2018-09-11 22:35 ` Dan Williams
2018-09-11 22:35 ` Dan Williams
2018-09-12 0:51 ` Alexander Duyck
2018-09-12 0:51 ` Alexander Duyck
2018-09-12 0:59 ` Dan Williams
2018-09-12 0:59 ` Dan Williams
2018-09-12 13:59 ` Pasha Tatashin
2018-09-12 15:48 ` Alexander Duyck
2018-09-12 15:48 ` Alexander Duyck
2018-09-12 15:54 ` Pasha Tatashin
2018-09-12 16:44 ` Alexander Duyck
2018-09-12 16:44 ` Alexander Duyck
2018-09-12 16:50 ` Dan Williams
2018-09-12 16:50 ` Dan Williams
2018-09-12 17:46 ` Pasha Tatashin
2018-09-12 19:11 ` Dan Williams
2018-09-12 19:11 ` Dan Williams
2018-09-10 23:44 ` [PATCH 4/4] nvdimm: Trigger the device probe on a cpu local to the device Alexander Duyck
2018-09-10 23:44 ` Alexander Duyck
2018-09-11 0:37 ` Alexander Duyck
2018-09-11 0:37 ` Alexander Duyck
2018-09-12 5:48 ` Dan Williams
2018-09-12 5:48 ` Dan Williams
2018-09-12 13:44 ` Pasha Tatashin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPcyv4j301Ma8D65oMzFo9-jVdwKGHzOVHb=7u9XaxACR5RAhg@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=dave.hansen@intel.com \
--cc=jglisse@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=pavel.tatashin@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.