08:53 arnd: I'm getting a new warning "drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c: In function 'kfd_topology_add_device':drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:2082:1: error: the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]"
08:54 arnd: it looks like the problem is "struct kfd_cu_info", which is huge, and ends up on the stack two or three times after inlining
08:54 airlied: agd5f: ^
12:52 agd5f: arnd, airlied: https://patchwork.freedesktop.org/patch/559044/
12:56 arnd: agd5f: right, that should avoid the warning by removing one of the copies. Another idea I had was to pass the copy from _add_device down into kfd_fill_cache_non_crat_info() to avoid having two of them on the stack after inlining
12:56 arnd: either approach makes it a bit uglier than it is, so I didn't try to send either one myself
12:58 arnd: agd5f: my third idea was to have the dynamic allocation in amdgpu_amdkfd_get_cu_info() to also avoid the copy of amdgpu_cu_info on the stack and return that from this function to be freed by the caller
12:59 arnd: that would be a somewhat larger rework because there are additional callers of this, but the result would seem nicer to me, as long as this could be made a GFP_KERNEL allocation and not require GFP_ATOMIC
13:01 agd5f: arnd, I think that would work. IIRC, that stuff only gets initialized at driver load time
13:04 arnd: if the information is completely static, then the extra on-stack copy in amdgpu_amdkfd_get_cu_info() become very easy to avoid, I wonder if that was just a mistake when it got introduced
15:12 agd5f: arnd, I think we can have amdgpu_amdkfd_get_cu_info() just return a pointer to adev->gfx.cu_info directly and skip the struct translation
15:13 agd5f: I think that is a leftover from when amdkfd supported both radeon and amdgpu so it needed an abstraction for both
15:21 arnd: ah, that would indeed be the best way, I could not figure out why there were two type, but if one works that simplifies it a lot