Re: slab warning: kmem_cache of name 'dm_bufio_buffer' already exists

[Vlastimil Babka <vbabka@suse.cz>]

On 11/6/24 22:22, Mikulas Patocka wrote:
> 
>> BTW, what benefits do you get from creating own kmem caches instead of using
>> kmalloc()? If it's just alignment, if you round up the intended size to
>> power of two, there's implicit kmalloc alignment guarantee.
> 
> See the function xfs_buf_alloc_kmem - it allocates a buffer using kmalloc, 
> tests if the buffer crosses a page boundary, and if it does, the code 
> falls back to xfs_buf_alloc_pages.
> 
> Do you think that it can be simplified to just allocate a buffer and NOT 
> check for page crossing?

Right, IIRC xfs was one of the usecases that prompted us towards defining
the kmalloc alignment guarantees, which was around 2019.
So today, kmalloc() allocations will not cross a page boundary if the
requested size is lower than page size, and it's a power-of-two value. Even
if SLUB debugging is enabled (before the alignment became guaranteed, it
would happen naturally, and only be violated by either using SLOB, or
enabling SLUB debugging).
xfs_buf_alloc_kmem() could be thus simplified.

>> AFAICS there's some alignment for c->slab_cache in 
>> dm_bufio_client_create()
> 
> There are two slab caches - one for the dm_buffer structure and one for 
> the buffer data (if the buffer size is less than a page).
> 
>> In case the allocations have odd sizes without any such alignment
>> (the case of c->slab_buffer?) separate size-specific caches can result in
>> better packing, but that should only matter if you expect many/long-lived
>> objects to be allocated.
> 
> The cache for the dm_buffer structure is there so that it utilizes memory 
> better. Yes - there may be a lot of long-lived dm_buffers in memory.

OK.

> Mikulas
>