TTM leaking swap space?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



It's on the amd-kfd-staging branch with some eviction fixes that are
still under developer testing, and a test that's still in development.
Not easy to share right now.

I'll look into ways to make it easier to reproduce. I'll experiment with
a driver change that deliberately swaps all BOs during allocation to see
if there is any obvious problem with swapping.

Regards,
  Felix


On 2018-01-16 10:24 PM, Chunming Zhou wrote:
> Hi Felix,
>
> Could I get your test to have a try?
>
>
> Thanks,
>
> David Zhou
>
>
> On 2018å¹´01æ??17æ?¥ 11:21, Felix Kuehling wrote:
>> I'm running an eviction stress test with KFD and find that sometimes it
>> starts swapping. When that happens, swap usage goes up rapidly, but it
>> never comes down. Even after the processes terminate, and all VRAM and
>> GTT allocations are freed (checked in
>> /sys/kernel/debug/dri/0/amdgpu_{gtt|vram}_mm), swap space is still not
>> released.
>>
>> Running the test repeatedly I was able to trigger the OOM killer quite
>> easily. The system died with a panic, running out of processes to kill.
>>
>> The symptoms look like swap space is only allocated but never released.
>>
>> A quick look at the swapping code in ttm_tt.c doesn't show any obvious
>> problems. I'm assuming that fput should free swap space. That should
>> happen when BOs are swapped back in, or destroyed. As far as I can tell,
>> amdgpu doesn't use persistent swap space, so I'm ignoring
>> TTM_PAGE_FLAG_PERSISTENT_SWAP.
>>
>> Any other ideas or pointers?
>>
>> Thanks,
>>    Felix
>>
>



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux