Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

s /Monk -----Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年3月5日 19:22 To: Liu, Monk <monk@amd.com>; Koenig, Christian <christian.koe...@amd.com>; dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH]

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

ntee that it is actually used. E.g. we can end up reserving a fence slot, but then find that we actually don't need it. Christian. Besides, the whole reservation logic still looks a little weired to me ... especially this staged part ... Thanks /Monk -Original Messa

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

little weired to me ... especially this staged part ... Thanks /Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年3月5日 19:22 To: Liu, Monk <monk@amd.com>; Koenig, Christian <christian.koe...@amd.com>; dri-de...@lists.freedeskto

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

especially this staged part ... Thanks /Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年3月5日 19:22 To: Liu, Monk ; Koenig, Christian ; dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] dma-buf/reservation: sho

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

d to me ... especially this staged part ... Thanks /Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年3月5日 19:22 To: Liu, Monk <monk@amd.com>; Koenig, Christian <christian.koe...@amd.com>; dri-de...@lists.freedesktop.org; linux

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

d to me ... especially this staged part ... Thanks /Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年3月5日 19:22 To: Liu, Monk ; Koenig, Christian ; dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH] dma-buf

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

o I can't fully answer. Maybe Chris or Maarten know more about that. Christian. Thanks /Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年2月28日 16:27 To: Liu, Monk <monk@amd.com>; dri-de...@lists.freedesktop.org; lin

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

o I can't fully answer. Maybe Chris or Maarten know more about that. Christian. Thanks /Monk -Original Message- From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] Sent: 2018年2月28日 16:27 To: Liu, Monk ; dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org Subject:

Re: [PATCH] PCI: stop crashing in pci_release_resource v2

Am 01.03.2018 um 19:49 schrieb Bjorn Helgaas: On Wed, Feb 21, 2018 at 10:07:15AM +0100, Christian König wrote: Is it entirely possible that the BIOS wasn't able to assign resources to a device. In this case don't crash in pci_release_resource() when we try to resize the resource. v2: keep

Re: [PATCH] PCI: stop crashing in pci_release_resource v2

Am 01.03.2018 um 19:49 schrieb Bjorn Helgaas: On Wed, Feb 21, 2018 at 10:07:15AM +0100, Christian König wrote: Is it entirely possible that the BIOS wasn't able to assign resources to a device. In this case don't crash in pci_release_resource() when we try to resize the resource. v2: keep

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

Am 28.02.2018 um 07:44 schrieb Monk Liu: under below scenario the obj->fence would refer to a wild pointer: 1,call reservation_object_reserved_shared 2,call reservation_object_add_shared_fence 3,call reservation_object_reserved_shared 4,call reservation_object_add_shared_fence in step 1,

Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

Am 28.02.2018 um 07:44 schrieb Monk Liu: under below scenario the obj->fence would refer to a wild pointer: 1,call reservation_object_reserved_shared 2,call reservation_object_add_shared_fence 3,call reservation_object_reserved_shared 4,call reservation_object_add_shared_fence in step 1,

Re: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and swapout.

-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 33 - 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index d90b1cf10b27..3a44c2ee4155 100644 --- a/drivers/g

Re: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and swapout.

-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 33 - 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index d90b1cf10b27..3a44c2ee4155 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers

Re: [PATCH 2/2] drm/amd: Remove inclusion of non-existing include directories

it spams a lot. Signed-off-by: Corentin Labbe <cla...@baylibre.com> Acked-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/display/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/Makefile b/drivers/gpu/drm/amd/display/Ma

Re: [PATCH 2/2] drm/amd: Remove inclusion of non-existing include directories

it spams a lot. Signed-off-by: Corentin Labbe Acked-by: Christian König --- drivers/gpu/drm/amd/display/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/Makefile b/drivers/gpu/drm/amd/display/Makefile index c27c81cdeed3..22c72dffdf98 100644

Re: [PATCH 1/2] drm/amd: remove inclusion of non-existing scheduler directory

Am 22.02.2018 um 09:21 schrieb Corentin Labbe: The scheduler directory was removed via commit 1b1f42d8fde4 ("drm: move amd_gpu_scheduler into common location") Remove it from include path. Signed-off-by: Corentin Labbe <cla...@baylibre.com> Reviewed-by: Christian Köni

Re: [PATCH 1/2] drm/amd: remove inclusion of non-existing scheduler directory

Am 22.02.2018 um 09:21 schrieb Corentin Labbe: The scheduler directory was removed via commit 1b1f42d8fde4 ("drm: move amd_gpu_scheduler into common location") Remove it from include path. Signed-off-by: Corentin Labbe Reviewed-by: Christian König --- drivers/gpu/drm/

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

Am 21.02.2018 um 11:54 schrieb Maarten Lankhorst: Op 21-02-18 om 00:56 schreef Daniel Vetter: On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote: On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote: Am 20.02.2018 um 15:54 schrieb Peter Zijlstra: On Tue, Feb 20, 2018

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

Am 21.02.2018 um 11:54 schrieb Maarten Lankhorst: Op 21-02-18 om 00:56 schreef Daniel Vetter: On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote: On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote: Am 20.02.2018 um 15:54 schrieb Peter Zijlstra: On Tue, Feb 20, 2018

[PATCH] locking/ww_mutex: add ww_mutex_is_owned_by function v5

owning the underlying mutex. v2: split amdgpu changes into separate patch as suggested by Alex v3: change logic as suggested by Daniel v4: fix test in case ctx is NULL v5: fix stupid typo and improve kerneldoc Signed-off-by: Christian König <christian.koe...@amd.com> Reviewed-by: Daniel

[PATCH] locking/ww_mutex: add ww_mutex_is_owned_by function v5

owning the underlying mutex. v2: split amdgpu changes into separate patch as suggested by Alex v3: change logic as suggested by Daniel v4: fix test in case ctx is NULL v5: fix stupid typo and improve kerneldoc Signed-off-by: Christian König Reviewed-by: Daniel Vetter --- include/linux/ww_mutex.h

[PATCH] PCI: stop crashing in pci_release_resource v2

Is it entirely possible that the BIOS wasn't able to assign resources to a device. In this case don't crash in pci_release_resource() when we try to resize the resource. v2: keep printing the info that we try to release the BAR Signed-off-by: Christian König <christian.koe...@amd.com> C

[PATCH] PCI: stop crashing in pci_release_resource v2

Is it entirely possible that the BIOS wasn't able to assign resources to a device. In this case don't crash in pci_release_resource() when we try to resize the resource. v2: keep printing the info that we try to release the BAR Signed-off-by: Christian König CC: sta...@vger.kernel.org

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

Am 20.02.2018 um 15:54 schrieb Peter Zijlstra: On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote: OK, but neither case would in fact need the !ctx case right? That's just there for completeness sake? Unfortunately not. TTM uses trylock to lock BOs which are about to be evicted

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

Am 20.02.2018 um 15:54 schrieb Peter Zijlstra: On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote: OK, but neither case would in fact need the !ctx case right? That's just there for completeness sake? Unfortunately not. TTM uses trylock to lock BOs which are about to be evicted

[PATCH] locking/ww_mutex: add ww_mutex_is_owned_by function v4

owning the underlying mutex. v2: split amdgpu changes into separate patch as suggested by Alex v3: change logic as suggested by Daniel v4: fix test in case ctx is NULL Signed-off-by: Christian König <christian.koe...@amd.com> --- include/linux/ww_mutex.h | 19 +++ 1 file c

[PATCH] locking/ww_mutex: add ww_mutex_is_owned_by function v4

owning the underlying mutex. v2: split amdgpu changes into separate patch as suggested by Alex v3: change logic as suggested by Daniel v4: fix test in case ctx is NULL Signed-off-by: Christian König --- include/linux/ww_mutex.h | 19 +++ 1 file changed, 19 insertions(+) diff

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

Am 20.02.2018 um 14:57 schrieb Peter Zijlstra: On Tue, Feb 20, 2018 at 02:26:55PM +0100, Christian König wrote: +static inline bool ww_mutex_is_owned_by(struct ww_mutex *lock, + struct ww_acquire_ctx *ctx) +{ + if (ctx) + return likely

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

Am 20.02.2018 um 14:57 schrieb Peter Zijlstra: On Tue, Feb 20, 2018 at 02:26:55PM +0100, Christian König wrote: +static inline bool ww_mutex_is_owned_by(struct ww_mutex *lock, + struct ww_acquire_ctx *ctx) +{ + if (ctx) + return likely

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

Am 20.02.2018 um 14:12 schrieb Peter Zijlstra: On Tue, Feb 20, 2018 at 01:58:26PM +0100, Christian König wrote: amdgpu needs to verify if userspace sends us valid addresses and the simplest way of doing this is to check if the buffer object is locked with the ticket of the current submission

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

Am 20.02.2018 um 14:12 schrieb Peter Zijlstra: On Tue, Feb 20, 2018 at 01:58:26PM +0100, Christian König wrote: amdgpu needs to verify if userspace sends us valid addresses and the simplest way of doing this is to check if the buffer object is locked with the ticket of the current submission

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 20.02.2018 um 13:35 schrieb Peter Zijlstra: This really should've been Cc'ed to me. On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote: diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h index 39fda195bf78..dd580db289e8 100644 --- a/include/linux/ww_mutex.h +++ b

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 20.02.2018 um 13:35 schrieb Peter Zijlstra: This really should've been Cc'ed to me. On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote: diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h index 39fda195bf78..dd580db289e8 100644 --- a/include/linux/ww_mutex.h +++ b

[PATCH 2/4] drm/amdgpu: use new ww_mutex_is_owned_by function

Instead of accessing ww_mutex internals directly use the provided function to check if the ww_mutex was indeed locked by the current command submission. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- 1 file changed, 1 insertion

[PATCH 2/4] drm/amdgpu: use new ww_mutex_is_owned_by function

Instead of accessing ww_mutex internals directly use the provided function to check if the ww_mutex was indeed locked by the current command submission. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 4/4] drm/ttm: keep BOs reserved until end of eviction

This avoids problems when BOs are evicted but directly moved back into the domain from other threads. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 37 + 1 file changed, 29 insertions(+), 8 deletions(-)

[PATCH 4/4] drm/ttm: keep BOs reserved until end of eviction

This avoids problems when BOs are evicted but directly moved back into the domain from other threads. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 37 + 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/ttm

[PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

owning the underlying mutex. v2: split amdgpu changes into separate patch as suggested by Alex v3: change logic as suggested by Daniel Signed-off-by: Christian König <christian.koe...@amd.com> --- include/linux/ww_mutex.h | 17 + 1 file changed, 17 insertions(+) diff

[PATCH 3/4] drm/ttm: handle already locked BOs during eviction and swapout.

This solves the problem that when we swapout a BO from a domain we sometimes couldn't make room for it because holding the lock blocks all other BOs with this reservation object. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.

[PATCH 3/4] drm/ttm: handle already locked BOs during eviction and swapout.

This solves the problem that when we swapout a BO from a domain we sometimes couldn't make room for it because holding the lock blocks all other BOs with this reservation object. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 33 - 1 file

[PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

owning the underlying mutex. v2: split amdgpu changes into separate patch as suggested by Alex v3: change logic as suggested by Daniel Signed-off-by: Christian König --- include/linux/ww_mutex.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/linux/ww_mutex.h b

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 20.02.2018 um 12:33 schrieb Daniel Vetter: [SNIP] Ah, so the ttm_ctx I've spotted was something entirely different and doesn't contain the ww_acquire_ctx (I didn't check)? I'd assume you have the same ctx passed around to everything in ttm, but if that doesn't exist then we can indeed not

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 20.02.2018 um 12:33 schrieb Daniel Vetter: [SNIP] Ah, so the ttm_ctx I've spotted was something entirely different and doesn't contain the ww_acquire_ctx (I didn't check)? I'd assume you have the same ctx passed around to everything in ttm, but if that doesn't exist then we can indeed not

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 19.02.2018 um 17:43 schrieb Daniel Vetter: On Mon, Feb 19, 2018 at 05:29:46PM +0100, Christian König wrote: [SNIP] Well that is not a problem at all. See we don't nest trylock with normal lock acquiring, cause that would indeed bypass the whole deadlock detection. Instead we first use

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 19.02.2018 um 17:43 schrieb Daniel Vetter: On Mon, Feb 19, 2018 at 05:29:46PM +0100, Christian König wrote: [SNIP] Well that is not a problem at all. See we don't nest trylock with normal lock acquiring, cause that would indeed bypass the whole deadlock detection. Instead we first use

[PATCH] PCI: stop crashing in pci_release_resource

Is it entirely possible that the BIOS wasn't able to assign resources to a device. In this case don't crash in pci_release_resource() when we try to resize the resource. Signed-off-by: Christian König <christian.koe...@amd.com> CC: sta...@vger.kernel.org --- drivers/pci/setup-res.c | 3

[PATCH] PCI: stop crashing in pci_release_resource

Is it entirely possible that the BIOS wasn't able to assign resources to a device. In this case don't crash in pci_release_resource() when we try to resize the resource. Signed-off-by: Christian König CC: sta...@vger.kernel.org --- drivers/pci/setup-res.c | 3 +++ 1 file changed, 3 insertions

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 19.02.2018 um 17:15 schrieb Daniel Vetter: On Mon, Feb 19, 2018 at 04:41:55PM +0100, Christian König wrote: Am 19.02.2018 um 16:24 schrieb Daniel Vetter: On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote: amdgpu needs to verify if userspace sends us valid addresses

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 19.02.2018 um 17:15 schrieb Daniel Vetter: On Mon, Feb 19, 2018 at 04:41:55PM +0100, Christian König wrote: Am 19.02.2018 um 16:24 schrieb Daniel Vetter: On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote: amdgpu needs to verify if userspace sends us valid addresses

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 19.02.2018 um 16:24 schrieb Daniel Vetter: On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote: amdgpu needs to verify if userspace sends us valid addresses and the simplest way of doing this is to check if the buffer object is locked with the ticket of the current submission

Re: [PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

Am 19.02.2018 um 16:24 schrieb Daniel Vetter: On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote: amdgpu needs to verify if userspace sends us valid addresses and the simplest way of doing this is to check if the buffer object is locked with the ticket of the current submission

[PATCH 2/4] drm/amdgpu: use new ww_mutex_is_owned_by function

Instead of accessing ww_mutex internals directly use the provided function to check if the ww_mutex was indeed locked by the current command submission. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++- 1 file changed, 2 inse

[PATCH 2/4] drm/amdgpu: use new ww_mutex_is_owned_by function

Instead of accessing ww_mutex internals directly use the provided function to check if the ww_mutex was indeed locked by the current command submission. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH 4/4] drm/ttm: keep BOs reserved until end of eviction

This avoids problems when BOs are evicted but directly moved back into the domain from other threads. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 37 + 1 file changed, 29 insertions(+), 8 deletions(-)

[PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function

owning the underlying mutex. Signed-off-by: Christian König <christian.koe...@amd.com> --- include/linux/ww_mutex.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h index 39fda195bf78..dd580db289e8 100644 --- a/include

[PATCH 4/4] drm/ttm: keep BOs reserved until end of eviction

This avoids problems when BOs are evicted but directly moved back into the domain from other threads. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 37 + 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/ttm

[PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function

owning the underlying mutex. Signed-off-by: Christian König --- include/linux/ww_mutex.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h index 39fda195bf78..dd580db289e8 100644 --- a/include/linux/ww_mutex.h +++ b/include

[PATCH 3/4] drm/ttm: handle already locked BOs during eviction and swapout.

This solves the problem that when we swapout a BO from a domain we sometimes couldn't make room for it because holding the lock blocks all other BOs with this reservation object. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.

[PATCH 3/4] drm/ttm: handle already locked BOs during eviction and swapout.

This solves the problem that when we swapout a BO from a domain we sometimes couldn't make room for it because holding the lock blocks all other BOs with this reservation object. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 33 - 1 file

[PATCH 2/3] drm/ttm: handle already locked BOs during eviction and swapout.

This solves the problem that when we swapout a BO from a domain we sometimes couldn't make room for it because holding the lock blocks all other BOs with this reservation object. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.

[PATCH 2/3] drm/ttm: handle already locked BOs during eviction and swapout.

This solves the problem that when we swapout a BO from a domain we sometimes couldn't make room for it because holding the lock blocks all other BOs with this reservation object. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 33 - 1 file

[PATCH 3/3] drm/ttm: keep BOs reserved until end of eviction

This avoids problems when BOs are evicted but directly moved back into the domain from other threads. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 37 + 1 file changed, 29 insertions(+), 8 deletions(-)

[PATCH 3/3] drm/ttm: keep BOs reserved until end of eviction

This avoids problems when BOs are evicted but directly moved back into the domain from other threads. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 37 + 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/ttm

[PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

owning the underlying mutex. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++- include/linux/ww_mutex.h | 17 + 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/

[PATCH 1/3] locking/ww_mutex: cleanup lock->ctx usage in amdgpu

owning the underlying mutex. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++- include/linux/ww_mutex.h | 17 + 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm

Re: [PATCH] drm/amdgpu_gem: fix error handling path in amdgpu_gem_va_update_vm

("Unused value") Fixes: 0abc6878fc2d ("drm/amdgpu: update VM PDs after the PTs") Signed-off-by: Gustavo A. R. Silva <gust...@embeddedor.com> Reviewed-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 7 --- 1 file chang

Re: [PATCH] drm/amdgpu_gem: fix error handling path in amdgpu_gem_va_update_vm

("Unused value") Fixes: 0abc6878fc2d ("drm/amdgpu: update VM PDs after the PTs") Signed-off-by: Gustavo A. R. Silva Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/driver

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Can you try to use a fixed limit like I suggested once more? E.g. just stop swapping if get_nr_swap_pages() < 256MB. Regards, Christian. Am 02.02.2018 um 07:57 schrieb He, Roger: Use the limit as total ram*1/2 seems work very well. No OOM although swap disk reaches full at

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Can you try to use a fixed limit like I suggested once more? E.g. just stop swapping if get_nr_swap_pages() < 256MB. Regards, Christian. Am 02.02.2018 um 07:57 schrieb He, Roger: Use the limit as total ram*1/2 seems work very well. No OOM although swap disk reaches full at

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Yeah, indeed. But what we could do is to rely on a fixed limit like the Intel driver does and I suggested before. E.g. don't copy anything into a shmemfile when there is only x MB of swap space left. Roger can you test that approach once more with your fix for the OOM issues in the page

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Yeah, indeed. But what we could do is to rely on a fixed limit like the Intel driver does and I suggested before. E.g. don't copy anything into a shmemfile when there is only x MB of swap space left. Roger can you test that approach once more with your fix for the OOM issues in the page

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Am 30.01.2018 um 13:28 schrieb Michal Hocko: I do think you should completely ignore the size of the swap space. IMHO you should forbid further allocations when your current buffer storage cannot be reclaimed. So you need some form of feedback mechanism that would tell you: "Your buffers have

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Am 30.01.2018 um 13:28 schrieb Michal Hocko: I do think you should completely ignore the size of the swap space. IMHO you should forbid further allocations when your current buffer storage cannot be reclaimed. So you need some form of feedback mechanism that would tell you: "Your buffers have

Re: [RFC] Per file OOM badness

Am 30.01.2018 um 12:42 schrieb Michel Dänzer: On 2018-01-30 12:36 PM, Nicolai Hähnle wrote: On 30.01.2018 12:34, Michel Dänzer wrote: On 2018-01-30 12:28 PM, Christian König wrote: Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um

Re: [RFC] Per file OOM badness

Am 30.01.2018 um 12:42 schrieb Michel Dänzer: On 2018-01-30 12:36 PM, Nicolai Hähnle wrote: On 30.01.2018 12:34, Michel Dänzer wrote: On 2018-01-30 12:28 PM, Christian König wrote: Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um

Re: [RFC] Per file OOM badness

Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget references essentially forever? If that's ok I think we can do your process based account

Re: [RFC] Per file OOM badness

Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget references essentially forever? If that's ok I think we can do your process based account

Re: [RFC] Per file OOM badness

Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget references essentially forever? If that's ok I think we can do your process based account (minus a few minor inaccuracies for shared stuff perhaps, but no one cares about that).

Re: [RFC] Per file OOM badness

Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget references essentially forever? If that's ok I think we can do your process based account (minus a few minor inaccuracies for shared stuff perhaps, but no one cares about that).

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Am 30.01.2018 um 11:18 schrieb Michal Hocko: On Tue 30-01-18 10:00:07, Christian König wrote: Am 30.01.2018 um 08:55 schrieb Michal Hocko: On Tue 30-01-18 02:56:51, He, Roger wrote: Hi Michal: We need a API to tell TTM module the system totally has how many swap cache. Then TTM module can

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Am 30.01.2018 um 11:18 schrieb Michal Hocko: On Tue 30-01-18 10:00:07, Christian König wrote: Am 30.01.2018 um 08:55 schrieb Michal Hocko: On Tue 30-01-18 02:56:51, He, Roger wrote: Hi Michal: We need a API to tell TTM module the system totally has how many swap cache. Then TTM module can

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Am 30.01.2018 um 08:55 schrieb Michal Hocko: On Tue 30-01-18 02:56:51, He, Roger wrote: Hi Michal: We need a API to tell TTM module the system totally has how many swap cache. Then TTM module can use it to restrict how many the swap cache it can use to prevent triggering OOM. For Now we set

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Am 30.01.2018 um 08:55 schrieb Michal Hocko: On Tue 30-01-18 02:56:51, He, Roger wrote: Hi Michal: We need a API to tell TTM module the system totally has how many swap cache. Then TTM module can use it to restrict how many the swap cache it can use to prevent triggering OOM. For Now we set

Re: [PATCH] drm/radeon: adjust tested variable

Am 27.01.2018 um 15:28 schrieb Julia Lawall: Check the variable that was most recently initialized. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression x, y, f, g, e, m; statement S1,S2,S3,S4; @@ x = f(...); if (\(<+...x...+>\\)) S1 else S2

Re: [PATCH] drm/radeon: adjust tested variable

Am 27.01.2018 um 15:28 schrieb Julia Lawall: Check the variable that was most recently initialized. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression x, y, f, g, e, m; statement S1,S2,S3,S4; @@ x = f(...); if (\(<+...x...+>\\)) S1 else S2

Re: [GIT PULL] PCI fixes for v4.15

Am 24.01.2018 um 17:40 schrieb Linus Torvalds: On Wed, Jan 24, 2018 at 8:20 AM, Bjorn Helgaas wrote: Bjorn, maybe you can send Catalin an example mbox? Attaching the one I used above. Heh. That's a mess. It has Content-Type: text/plain; charset=UTF-8 but then the

Re: [GIT PULL] PCI fixes for v4.15

Am 24.01.2018 um 17:40 schrieb Linus Torvalds: On Wed, Jan 24, 2018 at 8:20 AM, Bjorn Helgaas wrote: Bjorn, maybe you can send Catalin an example mbox? Attaching the one I used above. Heh. That's a mess. It has Content-Type: text/plain; charset=UTF-8 but then the name in the body is

Re: [RFC] Per file OOM badness

Am 24.01.2018 um 12:50 schrieb Michal Hocko: On Wed 24-01-18 12:23:10, Michel Dänzer wrote: On 2018-01-24 12:01 PM, Michal Hocko wrote: On Wed 24-01-18 11:27:15, Michel Dänzer wrote: [...] 2. If the OOM killer kills a process which is sharing BOs with another process, this should result in

Re: [RFC] Per file OOM badness

Am 24.01.2018 um 12:50 schrieb Michal Hocko: On Wed 24-01-18 12:23:10, Michel Dänzer wrote: On 2018-01-24 12:01 PM, Michal Hocko wrote: On Wed 24-01-18 11:27:15, Michel Dänzer wrote: [...] 2. If the OOM killer kills a process which is sharing BOs with another process, this should result in

Re: [RFC] Per file OOM badness

Am 19.01.2018 um 13:20 schrieb Michal Hocko: On Fri 19-01-18 13:13:51, Michal Hocko wrote: On Fri 19-01-18 12:37:51, Christian König wrote: [...] The per file descriptor badness is/was just the much easier approach to solve the issue, because the drivers already knew which client is currently

Re: [RFC] Per file OOM badness

Am 19.01.2018 um 13:20 schrieb Michal Hocko: On Fri 19-01-18 13:13:51, Michal Hocko wrote: On Fri 19-01-18 12:37:51, Christian König wrote: [...] The per file descriptor badness is/was just the much easier approach to solve the issue, because the drivers already knew which client is currently

Re: [RFC] Per file OOM badness

Am 19.01.2018 um 11:40 schrieb Michal Hocko: On Fri 19-01-18 09:39:03, Christian König wrote: Am 19.01.2018 um 09:20 schrieb Michal Hocko: [...] OK, in that case I would propose a different approach. We already have rss_stat. So why do not we simply add a new counter there MM_KERNELPAGES

Re: [RFC] Per file OOM badness

Am 19.01.2018 um 11:40 schrieb Michal Hocko: On Fri 19-01-18 09:39:03, Christian König wrote: Am 19.01.2018 um 09:20 schrieb Michal Hocko: [...] OK, in that case I would propose a different approach. We already have rss_stat. So why do not we simply add a new counter there MM_KERNELPAGES

Re: [RFC] Per file OOM badness

Am 19.01.2018 um 10:32 schrieb Michel Dänzer: On 2018-01-19 09:39 AM, Christian König wrote: Am 19.01.2018 um 09:20 schrieb Michal Hocko: On Thu 18-01-18 12:01:32, Eric Anholt wrote: Michal Hocko <mho...@kernel.org> writes: On Thu 18-01-18 18:00:06, Michal Hocko wrote: On Thu 18-01

Re: [RFC] Per file OOM badness

Am 19.01.2018 um 10:32 schrieb Michel Dänzer: On 2018-01-19 09:39 AM, Christian König wrote: Am 19.01.2018 um 09:20 schrieb Michal Hocko: On Thu 18-01-18 12:01:32, Eric Anholt wrote: Michal Hocko writes: On Thu 18-01-18 18:00:06, Michal Hocko wrote: On Thu 18-01-18 11:47:48, Andrey

Re: [RFC] Per file OOM badness

C sent by Christian König a few years ago. The original RFC can be found at https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html This is the same idea and I've just adressed his concern from the original RFC and switched to a callback into file_ops instead of a new member in struc

Re: [RFC] Per file OOM badness

Am 19.01.2018 um 09:20 schrieb Michal Hocko: On Thu 18-01-18 12:01:32, Eric Anholt wrote: Michal Hocko writes: On Thu 18-01-18 18:00:06, Michal Hocko wrote: On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: Hi, this series is a revised version of an RFC sent by Christian König a few years

Re: [RFC] Per file OOM badness

Am 18.01.2018 um 21:01 schrieb Eric Anholt: Michal Hocko writes: [SNIP] But files are not killable, they can be shared... In other words this doesn't help the oom killer to make an educated guess at all. Maybe some more context would help the discussion? Thanks for doing

Re: [RFC] Per file OOM badness

Am 18.01.2018 um 21:01 schrieb Eric Anholt: Michal Hocko writes: [SNIP] But files are not killable, they can be shared... In other words this doesn't help the oom killer to make an educated guess at all. Maybe some more context would help the discussion? Thanks for doing this. Wanted to

<    1   2   3   4   5   6   7   8   9   10   >