From: Dan Williams <email@example.com> To: Alexander Duyck <firstname.lastname@example.org> Cc: email@example.com, "Michal Hocko" <firstname.lastname@example.org>, linux-nvdimm <email@example.com>, "Dave Hansen" <firstname.lastname@example.org>, LKML <email@example.com>, linux-mm <firstname.lastname@example.org>, "Jérôme Glisse" <email@example.com>, "Andrew Morton" <firstname.lastname@example.org>, "Ingo Molnar" <email@example.com>, "Kirill A. Shutemov" <firstname.lastname@example.org> Subject: Re: [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning Date: Tue, 11 Sep 2018 13:24:29 -0700 [thread overview] Message-ID: <CAPcyv4gV1q1RE5ck=+GcdydrN-_x3AqKPxF2sbCUhsafUov1Gw@mail.gmail.com> (raw) In-Reply-To: <CAKgT0UddVdf=+SnfeZ2hL=a47YkjOa+r96xnghP8r1fQZ_1Ycw@mail.gmail.com> On Tue, Sep 11, 2018 at 1:01 PM, Alexander Duyck <email@example.com> wrote: > On Tue, Sep 11, 2018 at 9:50 AM Dan Williams <firstname.lastname@example.org> wrote: >> >> On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck >> <email@example.com> wrote: >> > From: Alexander Duyck <firstname.lastname@example.org> >> > >> > 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. > > Based on earlier discussions I would assume that CONFIG_DEBUG_VM would > imply CONFIG_DEBUG_VM_ON anyway since we don't want most of these > disabled by default. > > In my mind we should be looking at a selective "vm_debug_disable=" > instead of something that would be turning on features. Sorry, I missed those earlier discussions, so I won't push too hard if this has been hashed before. My proposal for opt-in is the fact that at least one known distribution kernel, Fedora, is shipping with CONFIG_DEBUG_VM=y. They also ship with CONFIG_SLUB, but not SLUB_DEBUG_ON. If we are going to picemeal enable some debug options to be runtime controlled I think we should go further to start clarifying the cheap vs the expensive checks and making the expensive checks opt-in in the same spirit of SLUB_DEBUG. _______________________________________________ Linux-nvdimm mailing list Linuxemail@example.com https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2018-09-11 20:24 UTC|newest] Thread overview: 31+ 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 ` [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning Alexander Duyck 2018-09-11 0:35 ` Alexander Duyck 2018-09-11 16:50 ` Dan Williams 2018-09-11 20:01 ` Alexander Duyck 2018-09-11 20:24 ` Dan Williams [this message] 2018-09-12 13:24 ` Pasha Tatashin 2018-09-12 14:10 ` Michal Hocko 2018-09-12 14:49 ` Alexander Duyck 2018-09-12 15:23 ` Dave Hansen 2018-09-12 16:36 ` Alexander Duyck 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-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-11 7:49 ` kbuild test robot 2018-09-11 7:54 ` kbuild test robot 2018-09-11 22:35 ` Dan Williams 2018-09-12 0:51 ` Alexander Duyck 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:54 ` Pasha Tatashin 2018-09-12 16:44 ` Alexander Duyck 2018-09-12 16:50 ` Dan Williams 2018-09-12 17:46 ` Pasha Tatashin 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-11 0:37 ` Alexander Duyck 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='CAPcyv4gV1q1RE5ck=+GcdydrN-_x3AqKPxF2sbCUhsafUov1Gw@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).