[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.22.394.2103161105430.342782@gentwo.de>
Date: Tue, 16 Mar 2021 11:07:36 +0100 (CET)
From: Christoph Lameter <cl@...two.de>
To: Yang Shi <shy828301@...il.com>
cc: Roman Gushchin <guro@...com>, Vlastimil Babka <vbabka@...e.cz>,
Xunlei Pang <xlpang@...ux.alibaba.com>,
Pekka Enberg <penberg@...nel.org>,
Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
David Rientjes <rientjes@...gle.com>,
Matthew Wilcox <willy@...radead.org>,
Shu Ming <sming56@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
Wen Yang <wenyang@...ux.alibaba.com>,
James Wang <jnwang@...ux.alibaba.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 0/4] mm/slub: Fix count_partial() problem
On Mon, 15 Mar 2021, Yang Shi wrote:
> > It seems like CONFIG_SLUB_DEBUG is a more popular option than CONFIG_SLUB_STATS.
> > CONFIG_SLUB_DEBUG is enabled on my Fedora workstation, CONFIG_SLUB_STATS is off.
> > I doubt an average user needs this data, so I'd go with CONFIG_SLUB_STATS.
>
> I think CONFIG_SLUB_DEBUG is enabled by default on most distros since
> it is supposed not incur too much overhead unless specific debug (i.e.
> red_zone) is turned on on demand.
Correct. CONFIG_SLUB_DEBUG includes the code so the debugging can be
enabled on Distro kernels with a kernel command line option. So you dont
have to recompile the kernel to find weird memory corruption issues from
strange device drivers.
Somehow my email address dropped off this thread.
Powered by blists - more mailing lists