Re: port-amd64/54988: possible memory leaks/swap problems

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

The following reply was made to PR port-amd64/54988; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: ad%netbsd.org@localhost, thorpej%me.com@localhost
Cc: gnats-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-amd64/54988: possible memory leaks/swap problems
Date: Mon, 13 Apr 2020 01:10:19 +0900

 thorpej@ wrote:
 
 > > On Apr 7, 2020, at 3:12 PM, Andrew Doran <ad%netbsd.org@localhost> wrote:
 > > 
 > > It wasn't leaking before that, so it's a good repro.  Looking with dtrace
 > > there are many allocations happenning in the DRM code which is probably the
 > > first place I'd look given that it's very X specific.  Will need to think
 > > about it some more.
 > 
 > Write a dtrace script that builds a stack trace histogram for any allocation from that bucket?
 
 In a private discussion, I was told the following dtrace script
 (for kmem-96 on NetBSD/i386 9.0 GENERIC):
 
 ---
 dtrace -n 'fbt::kmem_intr_alloc:entry /80 < (arg0 + 0) && (arg0 + 0) <= 84/ { @["alloc", stack()] = count() } fbt::kmem_intr_free:entry /80 < (arg1 + 0) && (arg1 + 0) <= 84/ { @["free", stack()] = count() } tick-10s { printa(@) }'
 ---
 
 On NetBSD/amd64 9.0 GENERIC, it looks kmem-160
 (not kmem-192 in -current, probably some DIAGNOSTIC?):
 
 ---
 dtrace -n 'fbt::kmem_intr_alloc:entry /128 < (arg0 + 0) && (arg0 + 0) <= 148/ { @["alloc", stack()] = count() } fbt::kmem_intr_free:entry /128 < (arg1 + 0) && (arg1 + 0) <= 148/ { @["free", stack()] = count() } tick-10s { printa(@) }'
 ---
 
 Note 'modload dtrace_profile' is necessary for "tick-10s".
 
 According to results of these dtrace, it looks the following kmalloc() in
 src/sys/external/bsd/drm2/dist/drm/radeon/radeon_fence.c:radeon_fence_emit():
 
  https://nxr.netbsd.org/xref/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_fence.c?r=1.15#141
 ---
     134 int radeon_fence_emit(struct radeon_device *rdev,
     135 		      struct radeon_fence **fence,
     136 		      int ring)
     137 {
     138 	u64 seq = ++rdev->fence_drv[ring].sync_seq[ring];
     139 
     140 	/* we are protected by the ring emission mutex */
     141 	*fence = kmalloc(sizeof(struct radeon_fence), GFP_KERNEL);
     142 	if ((*fence) == NULL) {
     143 		return -ENOMEM;
     144 	}
 ---
 
 I was also told the the fence memory would be free'ed from RCU GC thread
 (fence_put() -> fence_release() -> fence_free() -> fence_free_cb() ?)
 but it's too complicated for me to investegate.
 
 ---
 Izumi Tsutsui