Hello Ramesh Errabolu,
The patch 0f28cca87e9a: "drm/amdkfd: Extend KFD device topology to
surface peer-to-peer links" from May 26, 2022, leads to the following
Smatch static checker warning:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428
kfd_create_indirect_link_prop() warn: iterator u
Hello everyone,
To summarize the issue I'm trying to address here: Processes can allocate
resources through a file descriptor without being held responsible for it.
I'm not explaining all the details again. See here for a more deeply
description of the problem:
https://lwn.net/ml/linux-kernel/20
From: Andrey Grodzovsky
Some files allocate large amounts of memory on behalf of userspace without
any on disk backing store. This memory isn't necessarily mapped into the
address space, but should still accounts towards the RSS of a process just
like mapped shared pages do.
That information can
From: Andrey Grodzovsky
Try to make better decisions which process to kill based on
per file RSS.
Signed-off-by: Andrey Grodzovsky
---
mm/oom_kill.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 3c6cf9e3cd66..76a5ea73eb6a
This gives the OOM killer an additional hint which processes are
referencing shmem files with potentially no other accounting for them.
Signed-off-by: Christian König
---
mm/shmem.c | 16
1 file changed, 16 insertions(+)
diff --git a/mm/shmem.c b/mm/shmem.c
index a6f565308133..
Add the per file RSS to the memory management accounting.
This allows to see the per file RSS in tools like top as well.
Signed-off-by: Christian König
---
fs/proc/array.c | 7 +--
fs/proc/internal.h | 3 ++-
fs/proc/task_mmu.c | 6 --
fs/proc/task_nommu.c | 3 ++-
4 files chan
Just return the size of the DMA-buf in pages since pages allocated or
mapped through DMA-bufs are usually not accounted elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dm
From: Andrey Grodzovsky
Large amounts of VRAM are usually not CPU accessible, so they are not mapped
into the processes address space. But since the device drivers usually support
swapping buffers from VRAM to system memory we can still run into an out of
memory situation when userspace starts to
This allows the OOM killer to make a better decision which process to reap.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 956c72b5aa33..11
From: Andrey Grodzovsky
This allows the OOM killer to make a better decision which process to reap.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/driv
This allows the OOM killer to make a better decision which process to reap.
Signed-off-by: Christian König
---
drivers/gpu/drm/gma500/psb_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 1d8744f3e702..92c005aa6e9e
This allows the OOM killer to make a better decision which process to reap.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 90b0ce5051af..fc269
This allows the OOM killer to make a better decision which process to reap.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 561309d447
This allows the OOM killer to make a better decision which process to reap.
Signed-off-by: Christian König
---
drivers/gpu/drm/omapdrm/omap_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index eaf67b9e5f12..dff63
This allows the OOM killer to make a better decision which process to reap.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 01a5b47e95f9..99
This allows the OOM killer to make a better decision which process to reap.
Signed-off-by: Christian König
---
drivers/gpu/drm/tegra/drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 4cdc8faf798f..cc0c2fc57250 100644
--- a/d
MES requires mc wptr address for usermode queues.
Export bo gart address for mc wptr address.
Signed-off-by: Jack Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 10 --
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_mes_c
Two changes:
1. reducing unnecessary evict/unmap when range is not mapped to gpu.
2. adding always evict when flags is set to always_mapped.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/g
It is to add new options for always keeping gpu mapping
and custom of coarse grain allocation intead of fine
grain as default.
Signed-off-by: Eric Huang
---
include/uapi/linux/kfd_ioctl.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/
It is to give a chance for user to change default
flags setting, such as fine grain to coarse grain.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
b/drivers/gpu/drm/
On 6/23/2022 1:21 PM, David Hildenbrand wrote:
On 23.06.22 20:20, Sierra Guiza, Alejandro (Alex) wrote:
On 6/23/2022 2:57 AM, David Hildenbrand wrote:
On 23.06.22 01:16, Sierra Guiza, Alejandro (Alex) wrote:
On 6/21/2022 11:16 AM, David Hildenbrand wrote:
On 21.06.22 18:08, Sierra Guiza, Al
Yiqing raised a problem of negative fence refcount for resubmitted jobs
in amdgpu and suggested a workaround in [1]. I took a look myself and
discovered
some deeper problems both in amdgpu and scheduler code.
Yiqing helped with testing the new code and also drew a detailed refcount and
flow
tra
Problem:
This patch caused negative refcount as described in [1] because
for that case parent fence did not signal by the time of drm_sched_stop and
hence
kept in pending list the assumption was they will not signal and
so fence was put to account for the s_fence->parent refcount but for
amdgpu wh
Problem:
After we start handling timed out jobs we assume there fences won't be
signaled but we cannot be sure and sometimes they fire late. We need
to prevent concurrent accesses to fence array from
amdgpu_fence_driver_clear_job_fences during GPU reset and amdgpu_fence_process
from a late EOP inte
Align refcount behaviour for amdgpu_job embedded HW fence with
classic pointer style HW fences by increasing refcount each
time emit is called so amdgpu code doesn't need to make workarounds
using amdgpu_job.job_run_counter to keep the HW fence refcount balanced.
Also since in the previous patch w
This function should drop the fence refcount when it extracts the
fence from the fence array, just as it's done in amdgpu_fence_process.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 4 +++-
1 file changed, 3 insertions(+), 1 delet
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2f9cb3d3bd73fc2225d66aa8fcffb632ed3eb235 Add linux-next specific
files for 20220624
Error/Warning reports:
https://lore.kernel.org/llvm/202206221813.dn1s6uuh-...@intel.com
Error/Warning
On Sun, Jun 19, 2022 at 10:53:03AM -0700, Rob Clark wrote:
> On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
> wrote:
> > + mutex_unlock(&gem_shrinker->lock);
>
> As I mentioned on other thread, count_objects, being approximate but
> lockless and fast is the important thing. Otherwise when
On Mon, Jun 20, 2022 at 08:18:04AM -0700, Rob Clark wrote:
> On Mon, Jun 20, 2022 at 7:09 AM Dmitry Osipenko
> wrote:
> >
> > On 6/19/22 20:53, Rob Clark wrote:
> > ...
> > >> +static unsigned long
> > >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> > >> +
On Sun, Jun 19, 2022 at 09:31:03PM -0100, Melissa Wen wrote:
> Add 3D LUT for gammar correction using a 3D lookup table. The position
> in the color correction pipeline where 3D LUT is applied depends on hw
> design, being after CTM or gamma. If just after CTM, a shaper lut must
> be set to shape
30 matches
Mail list logo
