out later.
So it did not break anything with this patch I think.
*From:* Pan, Xinhui
*Sent:* Thursday, April 9, 2020 10:07:09 PM
*To:* Lucas Stach ;
amd-...@lists.freedesktop.org ;
Koenig, Christian
*Cc:* dri-devel@lists.freedesktop.org
*Subject:* Re: [PATCH] drm/ttm: Schedule out if poss
inux/latest/source/mm/slab.c#L4026
>>
>> This is another example of the usage of cond_sched.
>> From: Pan, Xinhui
>> Sent: Thursday, April 9, 2020 10:11:08 PM
>> To: Lucas Stach ; amd-...@lists.freedesktop.org
>> ; Koenig, Christian
>> Cc: dri-devel@lis
10:11:08 PM
*To:* Lucas Stach ;
amd-...@lists.freedesktop.org ; Koenig,
Christian
*Cc:* dri-devel@lists.freedesktop.org
*Subject:* Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed
delete worker
I think it doesn't matter if workitem schedule out. Even we did not
schedule out, the workqueue i
@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete
worker
I think it doesn't matter if workitem schedule out. Even we did not schedule
out, the workqueue itself will schedule out later.
So it did not break anything with this patch I
; amd-...@lists.freedesktop.org
; Koenig, Christian
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete
worker
Why we break out the loops when there are pending bos to be released?
And I just checked the process_one_work. Right afte
From: Koenig, Christian
Sent: Thursday, April 9, 2020 9:38:24 PM
To: Lucas Stach ; Pan, Xinhui ;
amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete
worker
Am 09.04.20 um 15:25 schrieb Lucas Stach
Am 09.04.20 um 15:25 schrieb Lucas Stach:
Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:
Am 09.04.20 um 03:31 schrieb xinhui pan:
The delayed delete list is per device which might be very huge. And in
a heavy workload test, the list might always not be empty. That will
trig
Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König:
> Am 09.04.20 um 03:31 schrieb xinhui pan:
> > The delayed delete list is per device which might be very huge. And in
> > a heavy workload test, the list might always not be empty. That will
> > trigger any RCU stall warnings or so
Am 09.04.20 um 03:31 schrieb xinhui pan:
The delayed delete list is per device which might be very huge. And in
a heavy workload test, the list might always not be empty. That will
trigger any RCU stall warnings or softlockups in non-preemptible kernels
Lets do schedule out if possible in that ca
The delayed delete list is per device which might be very huge. And in
a heavy workload test, the list might always not be empty. That will
trigger any RCU stall warnings or softlockups in non-preemptible kernels
Lets do schedule out if possible in that case.
Signed-off-by: xinhui pan
---
driver
10 matches
Mail list logo
