[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0690ac12-e112-9e14-e228-4692af446265@suse.cz>
Date: Tue, 16 Mar 2021 11:32:17 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Christoph Lameter <cl@...two.de>, Yang Shi <shy828301@...il.com>
Cc: Roman Gushchin <guro@...com>,
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 3/16/21 11:07 AM, Christoph Lameter wrote:
> 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.
Hm I can imagine that (after due performance testing) we would consider having
accurate slabinfo in our distro kernel, just as we have CONFIG_SLUB_DEBUG but
not the full 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.
Hm I see cl@...ux.com in all e-mails of the thread, but now you replaced it with
cl@...two.de ?
Powered by blists - more mailing lists