On Fri, Oct 30, 2020 at 11:56:48PM +0100, Vlastimil Babka wrote:
> On 10/30/20 5:27 PM, Luis Chamberlain wrote:
> > On Mon, Oct 26, 2020 at 06:33:57PM +0100, Vlastimil Babka wrote:
> > > Commit 11c9c7edae06 ("mm/page_poison.c: replace bool variable with static key")
> > > changed page_poisoning_enabled() to a static key check. However, the function
> > > is not inlined, so each check still involves a function call with overhead not
> > > eliminated when page poisoning is disabled.
> > >
> > > Analogically to how debug_pagealloc is handled, this patch converts
> > > page_poisoning_enabled() back to boolean check, and introduces
> > > page_poisoning_enabled_static() for fast paths. Both functions are inlined.
> > >
> > > Also optimize the check that enables page poisoning instead of debug_pagealloc
> > > for architectures without proper debug_pagealloc support. Move the check to
> > > init_mem_debugging() to enable a single static key instead of having two
> > > static branches in page_poisoning_enabled_static().
> > >
> > > Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx>
> >
> > <sad trombone>
> >
> > This patchset causes a regression x86_64 as a guest. I was able
> > to bisect this on the following linux-next tags:
> >
> > next-20201015 OK
> > next-20201023 OK
> > next-20201026 OK
> > next-20201027 BAD
> > next-20201028 BAD
> >
> > Bisection inside next-20201027 lands me on:
> >
> > "mm, page_alloc: do not rely on the order of page_poison and init_on_alloc/free parameters"
>
> CC peterz.
>
> I wonder if it's because I converted some static keys to _RO
> DEFINE_STATIC_KEY_FALSE_RO(init_on_alloc);.
> ...
> DEFINE_STATIC_KEY_FALSE_RO(init_on_free);
This was along the lines of what I suspected but I didn't have time
to provide an alternative.
> I thought it was ok since we only enable them during init. But maybe it's
> incompatible with use by modules? Not that I immediately see how
> drm_kms_helper(E+) uses them.
I can reproduce easily so happy to test alterantive patchsets!
> Andrew, I'm fine if you drop the patchset for now. I fear the next version
> would be tedious to integrate in form of -fix-fix patches anyway...
Thanks for this, I confirm next-20201111 boots fine now on kdevops.
Luis
