From: Mikulas Patocka <mpatocka@redhat.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Pedro Falcato <pedro.falcato@gmail.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
zkabelac@redhat.com, Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
linux-mm@kvack.org
Subject: Re: slab warning: kmem_cache of name 'dm_bufio_buffer' already exists
Date: Wed, 6 Nov 2024 13:05:38 +0100 (CET) [thread overview]
Message-ID: <27ba7473-9255-2407-8e4e-e5c3cafc25c4@redhat.com> (raw)
In-Reply-To: <5a1e67c3-481e-4c6e-8507-5a8ea0bd9f28@suse.cz>
On Wed, 6 Nov 2024, Vlastimil Babka wrote:
> On 11/6/24 12:19, Mikulas Patocka wrote:
> > Hi
>
> Hi,
>
> > The commit 4c39529663b93165953ecf9b1a9ea817358dcd06 ("slab: Warn on
> > duplicate cache names when DEBUG_VM=y") is causing large number of
> > warnings about "dm_bufio_buffer", "dm_bufio_buffer-%u" (and other) device
> > mapper caches.
>
> Hmm wonder why nobody run into this before. We thought the code that would
> cause the warning would be all fixed before introducing it, but we missed
> some, sorry.
>
> > I'd like to ask - how to properly fix it?
> >
> > We create a "dm_bufio_buffer" or "dm_bufio_buffer-%u" cache with every dm
> > bufio client. It used to work (and the duplicate caches are merged), but
>
> Note the merging can be disabled so then it's really several caches with
> exactly same name in /proc/slabinfo and inability to create their
> sysfs/debugfs directories.
Would it be sensible to allow merging caches with the same name and same
attributes and only warn if there are caches with the same name and
different attributes?
> > now it warns.
> >
> > Should I append a pointer to the dm_bufio structure to the slab cache name
> > to make them different? Or is there any other preferred solution?
>
> Anything that uniquely identifies the client should be ok, but beware e.g.
> device names that can have slashes, see commit a360f311f57a36 (also for the
> simplest possible fix that is an incremented number).
>
> > Note that it is not possible to pre-create the cache "dm_bufio_buffer-%u"
> > in the module's init function, because the size of per-buffer auxiliary
> > data is not known at this point.
>
> Looks like some chose to solve this the harder way, see 4d784c042d164f
This seems too complicated.
The always increasing sequence number seems like a better soltion.
Mikulas
next prev parent reply other threads:[~2024-11-06 12:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 11:19 Mikulas Patocka
2024-11-06 11:34 ` Vlastimil Babka
2024-11-06 12:05 ` Mikulas Patocka [this message]
2024-11-06 16:28 ` Vlastimil Babka
2024-11-06 21:22 ` Mikulas Patocka
2024-11-08 9:56 ` Vlastimil Babka
2024-11-08 11:13 ` Hyeonggon Yoo
2024-11-08 11:21 ` Vlastimil Babka
2024-11-08 13:47 ` Pedro Falcato
2024-11-08 10:08 ` Vlastimil Babka
2024-11-08 14:56 ` Christoph Hellwig
2024-11-08 16:49 ` Yang Shi
2024-11-08 17:00 ` Vlastimil Babka
2024-11-08 17:43 ` Yang Shi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27ba7473-9255-2407-8e4e-e5c3cafc25c4@redhat.com \
--to=mpatocka@redhat.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=pedro.falcato@gmail.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
--cc=zkabelac@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox