[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98411844-19b7-a75b-d52c-6e2c46b40d57@intel.com>
Date: Wed, 26 Sep 2018 08:41:29 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
Michal Hocko <mhocko@...nel.org>
Cc: linux-mm@...ck.org, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-nvdimm@...ts.01.org,
pavel.tatashin@...rosoft.com, dave.jiang@...el.com,
jglisse@...hat.com, rppt@...ux.vnet.ibm.com,
dan.j.williams@...el.com, logang@...tatee.com, mingo@...nel.org,
kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v5 2/4] mm: Provide kernel parameter to allow disabling
page init poisoning
On 09/26/2018 08:24 AM, Alexander Duyck wrote:
> With no options it works just like slub_debug and enables all
> available options. So in our case it is a NOP since we wanted the
> debugging enabled by default.
Yeah, but slub_debug is different.
First, nobody uses the slub_debug=- option because *that* is only used
when you have SLUB_DEBUG=y *and* CONFIG_SLUB_DEBUG_ON=y, which not even
Fedora does.
slub_debug is *primarily* for *adding* debug features. For this, we
need to turn them off.
It sounds like following slub_debug was a bad idea, especially following
its semantics too closely when it doesn't make sense.
Powered by blists - more mailing lists