On Fri, 9 Oct 2026 20:39:54 +0300 Dmitry Osipenko wrote:
>27.09.2026 07:09, Nguyen Ngoc Thang пишет:
>> On Sun, 27 Sep 2026, Hillf Danton wrote:
>>> What is unclear -- why is kmalloc failing to work in 2026?
>>
>> kmalloc isn't failing. The failure is in kmem_cache_create(): the driver
>> creates a dedicated cache with a fixed global name for each device, so a
>> second probe while the first drm_device is still alive (release is
>> deferred by an open /dev/fbN) trips the duplicate-name check.
>>
>> Your question made me look at whether the dedicated cache is needed at all.
>> A vbuf is sizeof(struct virtio_gpu_vbuffer) + 96 + 24 = 216 bytes, which
>> lands in kmalloc-256 anyway, so the cache buys nothing over
>> kzalloc()/kfree().
>> Dropping it also removes the lifetime problem entirely and needs no
>> module-level state.
>>
>> I'll send a v2 that switches the kmem_cache_zalloc() calls and
>> kmem_cache_free() to kzalloc()/kfree() and deletes the cache setup and
>> teardown.
>>
>> Thanks,
>> Nguyen Ngoc Thang
>
> kmem_cache is used by GPU drivers to avoid kmalloc stalls in a
> latency-sensitive job-submission code path.
>
This makes no sense before showing the stall, given my failure of locating
the lore page where the tglx dude was taught a few years back (by Mathew
Wilcox?) that the percpu page is faster that thought.
