* Re: possible IO map leak in drm/gem [not found] <632F0FCB-8719-4E8B-B35A-DC0A2DF49369@oracle.com> @ 2021-01-21 14:47 ` Thomas Zimmermann 2021-01-21 15:05 ` Chuck Lever 0 siblings, 1 reply; 4+ messages in thread From: Thomas Zimmermann @ 2021-01-21 14:47 UTC (permalink / raw) To: Chuck Lever; +Cc: dri-devel [-- Attachment #1.1.1: Type: text/plain, Size: 2142 bytes --] (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@lists.freedesktop.org > 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. Best regards Thomas [1] https://lore.kernel.org/dri-devel/20210118144639.27307-1-tzimmermann@suse.de/ > > 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 [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: possible IO map leak in drm/gem 2021-01-21 14:47 ` possible IO map leak in drm/gem Thomas Zimmermann @ 2021-01-21 15:05 ` Chuck Lever 2021-01-22 14:27 ` Chuck Lever 0 siblings, 1 reply; 4+ messages in thread From: Chuck Lever @ 2021-01-21 15:05 UTC (permalink / raw) To: Thomas Zimmermann; +Cc: dri-devel > On Jan 21, 2021, at 9:47 AM, Thomas Zimmermann <tzimmermann@suse.de> 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@lists.freedesktop.org > >> 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. > Best regards > Thomas > > [1] https://lore.kernel.org/dri-devel/20210118144639.27307-1-tzimmermann@suse.de/ > >> 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: possible IO map leak in drm/gem 2021-01-21 15:05 ` Chuck Lever @ 2021-01-22 14:27 ` Chuck Lever 2021-01-22 14:46 ` Thomas Zimmermann 0 siblings, 1 reply; 4+ messages in thread From: Chuck Lever @ 2021-01-22 14:27 UTC (permalink / raw) To: Thomas Zimmermann; +Cc: dri-devel > On Jan 21, 2021, at 10:05 AM, Chuck Lever <chuck.lever@oracle.com> wrote: > > > >> On Jan 21, 2021, at 9:47 AM, Thomas Zimmermann <tzimmermann@suse.de> 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@lists.freedesktop.org >> >>> 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@oracle.com> >> Best regards >> Thomas >> >> [1] https://lore.kernel.org/dri-devel/20210118144639.27307-1-tzimmermann@suse.de/ >> >>> 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: possible IO map leak in drm/gem 2021-01-22 14:27 ` Chuck Lever @ 2021-01-22 14:46 ` Thomas Zimmermann 0 siblings, 0 replies; 4+ messages in thread From: Thomas Zimmermann @ 2021-01-22 14:46 UTC (permalink / raw) To: Chuck Lever; +Cc: dri-devel [-- Attachment #1.1.1: Type: text/plain, Size: 3095 bytes --] Hi Am 22.01.21 um 15:27 schrieb Chuck Lever: > > >> On Jan 21, 2021, at 10:05 AM, Chuck Lever <chuck.lever@oracle.com> wrote: >> >> >> >>> On Jan 21, 2021, at 9:47 AM, Thomas Zimmermann <tzimmermann@suse.de> 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@lists.freedesktop.org >>> >>>> 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@oracle.com> Great. Thanks a lot for testing. Best regards Thomas > > >>> Best regards >>> Thomas >>> >>> [1] https://lore.kernel.org/dri-devel/20210118144639.27307-1-tzimmermann@suse.de/ >>> >>>> 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 > > > -- 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 [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-01-23 9:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <632F0FCB-8719-4E8B-B35A-DC0A2DF49369@oracle.com>
2021-01-21 14:47 ` possible IO map leak in drm/gem Thomas Zimmermann
2021-01-21 15:05 ` Chuck Lever
2021-01-22 14:27 ` Chuck Lever
2021-01-22 14:46 ` Thomas Zimmermann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.