> On Jan 21, 2021, at 10:05 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>
>
>
>> On Jan 21, 2021, at 9:47 AM, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
>>
>> (cc'ing dri-devel)
>>
>> Hi,
>>
>> thanks for reporting the bug.
>>
>> Am 21.01.21 um 15:35 schrieb Chuck Lever:
>>> Hi Thomas-
>>> I was not able to find an appropriate mailing list entry in MAINTAINERS,
>>
>> That would be dri-devel@xxxxxxxxxxxxxxxxxxxxx
>>
>>> so I'm mailing you directly as committer of record for:
>>> 43676605f890 ("drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers")
>>> I've noticed that since putting v5.11-rc on my test systems, overnight
>>> on an otherwise idle system the load average seems to grow as the result
>>> of a kernel worker thread.
>>
>> Earlier this week I fixed a couple of leaks in that code. Could you please apply the patch at [1] and report back if it fixes the issue.
>>
>> If it's a separate problem, I'll take a closer look.
>
> Thomas, thank you for your quick response. I've installed your patch
> on one system and it looks promising already. I'll let it soak overnight.
All symptoms appear to be gone. Fwiw,
Tested-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
>> Best regards
>> Thomas
>>
>> [1] https://lore.kernel.org/dri-devel/20210118144639.27307-1-tzimmermann@xxxxxxx/
>>
>>> I used "perf top" to see what it had gotten up to, and it appears that
>>> it was spending lots of time walking an interval tree on behalf of
>>> memtype_reserve().
>>> The most frequently-observed stack trace seems to be:
>>> kworker/3:1-2355 [003] 60950.150928: function: memtype_reserve
>>> kworker/3:1-2355 [003] 60950.150942: kernel_stack: <stack trace>
>>> => ffffffffc0c66083
>>> => memtype_reserve (ffffffffa005f9d5)
>>> => __ioremap_caller (ffffffffa005aac1)
>>> => ttm_bo_vmap (ffffffffc040f266)
>>> => drm_gem_vram_vmap (ffffffffc042c5cd)
>>> => drm_gem_vmap (ffffffffc0506a7f)
>>> => drm_client_buffer_vmap (ffffffffc0523741)
>>> => drm_fb_helper_damage_work (ffffffffc049a34a)
>>> => process_one_work (ffffffffa00dd92e)
>>> => worker_thread (ffffffffa00dde46)
>>> => kthread (ffffffffa00e22c4)
>>> => ret_from_fork (ffffffffa0004192)
>>> I see a regular call to memtype_reserve(), but never a matching call to
>>> memtype_free(), thus I suspect a leak of I/O maps in this code.
>>> --
>>> Chuck Lever
>>
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>> (HRB 36809, AG Nürnberg)
>> Geschäftsführer: Felix Imendörffer
>
> --
> Chuck Lever
--
Chuck Lever
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
