On Wed, Sep 12, 2018 at 8:25 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 09/12/2018 07:49 AM, Alexander Duyck wrote: > >>> + page_init_poison= [KNL] Boot-time parameter changing the > >>> + state of poisoning of page structures during early > >>> + boot. Used to verify page metadata is not accessed > >>> + prior to initialization. Available with > >>> + CONFIG_DEBUG_VM=y. > >>> + off: turn off poisoning > >>> + on: turn on poisoning (default) > >>> + > >> what about the following wording or something along those lines > >> > >> Boot-time parameter to control struct page poisoning which is a > >> debugging feature to catch unitialized struct page access. This option > >> is available only for CONFIG_DEBUG_VM=y and it affects boot time > >> (especially on large systems). If there are no poisoning bugs reported > >> on the particular system and workload it should be safe to disable it to > >> speed up the boot time. > > That works for me. I will update it for the next release. > > FWIW, I rather liked Dan's idea of wrapping this under > vm_debug=<something>. We've got a zoo of boot options and it's really > hard to _remember_ what does what. For this case, we're creating one > that's only available under a specific debug option and I think it makes > total sense to name the boot option accordingly. > > For now, I think it makes total sense to do vm_debug=all/off. If, in > the future, we get more options, we can do things like slab does and do > vm_debug=P (for Page poison) for this feature specifically. > > vm_debug = [KNL] Available with CONFIG_DEBUG_VM=y. > May slow down boot speed, especially on larger- > memory systems when enabled. > off: turn off all runtime VM debug features > all: turn on all debug features (default) This would introduce a significant amount of code change if we do it as a parameter that has control over everything. I would be open to something like "vm_debug_disables=" where we could then pass individual values like 'P' for disabling page poisoning. However doing this as a generic interface that could disable everything now would be messy. I could then also update the print message so that it lists what is disabled, and what was left enabled. Then as we need to disable things in the future we could add additional letters for individual features. I just don't want us preemptively adding control flags for features that may never need to be toggled. I would want to hear from Michal on this before I get too deep into it as he seemed to be of the opinion that we were already doing too much code for this and it seems like this is starting to veer off in that direction. - Alex
