I can see is to avoid firefox, chrome for
example is reported to work perfectly fine.
Christian.
Cheers,
Jean-Marc
On 04/06/2018 04:03 AM, Christian König wrote:
Hi Jean,
yeah, that is a known problem. Using huge pages improves the performance
because of better TLB usage, but for
Am 06.04.2018 um 11:33 schrieb Gerd Hoffmann:
Hi,
The pages backing a DMA-buf are not allowed to move (at least not without a
patch set I'm currently working on), but for certain MM operations to work
correctly you must be able to modify the page tables entries and move the
pages backing the
gi?id=105038
Regards,
Christian.
Am 06.04.2018 um 10:03 schrieb Christian König:
Hi Jean,
yeah, that is a known problem. Using huge pages improves the
performance because of better TLB usage, but for the cost of higher
allocation overhead.
What we found is that firefox is doing something r
lling to be really choppy/sluggish. I've confirmed that the
problem is also there on 4.16, while 4.13 works fine.
After a bisection, I've narrowed the regression down to this commit:
commit 648bc3574716400acc06f99915815f80d9563783
Author: Christian König
Date: Thu Jul 6 09:59:43 2017
Am 05.04.2018 um 00:32 schrieb Eric Anholt:
These comments answer all the questions I had for myself when
implementing a driver using the GPU scheduler.
Signed-off-by: Eric Anholt
Reviewed-by: Christian König
Already pushed to amd-staging-drm-next as well.
Thanks,
Christian
Am 29.03.2018 um 18:25 schrieb Logan Gunthorpe:
On 29/03/18 10:10 AM, Christian König wrote:
Why not? I mean the dma_map_resource() function is for P2P while other
dma_map_* functions are only for system memory.
Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
P2P. T
Am 29.03.2018 um 17:45 schrieb Logan Gunthorpe:
On 29/03/18 05:44 AM, Christian König wrote:
Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:
On 28/03/18 01:44 PM, Christian König wrote:
Well, isn't that exactly what dma_map_resource() is good for? As far as
I can see it makes sure IOM
Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:
On 28/03/18 01:44 PM, Christian König wrote:
Well, isn't that exactly what dma_map_resource() is good for? As far as
I can see it makes sure IOMMU is aware of the access route and
translates a CPU address into a PCI Bus address.
I'm
Am 29.03.2018 um 08:57 schrieb Daniel Vetter:
On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote:
Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.
Signed-off-by: Christian König
Um strictly speaking they all should, but
Am 28.03.2018 um 20:57 schrieb Logan Gunthorpe:
On 28/03/18 12:28 PM, Christian König wrote:
I'm just using amdgpu as blueprint because I'm the co-maintainer of it
and know it mostly inside out.
Ah, I see.
The resource addresses are translated using dma_map_resource(). As far
as I
Am 28.03.2018 um 18:25 schrieb Logan Gunthorpe:
On 28/03/18 10:02 AM, Christian König wrote:
Yeah, that looks very similar to what I picked up from the older
patches, going to read up on that after my vacation.
Yeah, I was just reading through your patchset and there are a lot of
similarities
ng 'select MMU_NOTIFIER' line to make it build
cleanly all the time.
Signed-off-by: Arnd Bergmann
Acked-by: Christian König , but I would wait
on what Felix says to that.
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/a
Am 28.03.2018 um 17:47 schrieb Logan Gunthorpe:
On 28/03/18 09:07 AM, Christian König wrote:
Am 28.03.2018 um 14:38 schrieb Christoph Hellwig:
On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote:
From: "wda...@nvidia.com"
Add an interface to find the first devic
Am 28.03.2018 um 14:38 schrieb Christoph Hellwig:
On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote:
From: "wda...@nvidia.com"
Add an interface to find the first device which is upstream of both
devices.
Please work with Logan and base this on top of the outstandi
From: "wda...@nvidia.com"
Add an interface to find the first device which is upstream of both
devices.
Signed-off-by: Will Davis
Signed-off-by: Christian König
---
drivers/pci/search.c | 24
include/linux/pci.h | 2 ++
2 files changed, 26 insertions(+)
We should be able to do this now after checking all the prerequisites.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c| 44 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 9 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 91
From: "wda...@nvidia.com"
Add checks for topology and ACS configuration to determine whether or not
peer traffic should be supported between two PCI devices.
Signed-off-by: Will Davis
Signed-off-by: Christian König
---
drivers/pci/pci
Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 1 +
include/linux/dma-buf.h | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers
Importing should work out of the box.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index fb43faf88eb0..2566268806c3 100644
Just note if a BO was imported/exported.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 46b9ea4e6103
Use this function to set an sg entry to point to device resources mapped
using dma_map_resource(). The page pointer is set to NULL and only the DMA
address, length and offset values are valid.
Signed-off-by: Christian König
---
include/linux/scatterlist.h | 23 +++
1 file
Check if we can do peer2peer on the PCIe bus.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index
David Rientjes
Cc: Michal Hocko
Cc: Dan Williams
Cc: Joerg Roedel
Cc: Christian König
Cc: Paolo Bonzini
Cc: Leon Romanovsky
Cc: Artemy Kovalyov
Cc: Evgeny Baskakov
Cc: Ralph Campbell
Cc: Mark Hairgrove
Cc: John Hubbard
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Cc: Alex Deucher
Cc: Sudeep
Am 22.03.2018 um 16:41 schrieb Colin King:
From: Colin Ian King
Trivial fix to spelling mistake in pr_err error message text
Signed-off-by: Colin Ian King
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Forwarding to LKML once more because Outlook decided to change it to
HTML mail.
Christian.
Am 19.03.2018 um 12:06 schrieb Julia Lawall:
On Mon, 19 Mar 2018, Christian König wrote:
Mhm, actually that patch isn't correct. What we grab get here is the next
entry, not the first one.
We
Mhm, actually that patch isn't correct. What we grab get here is the
next entry, not the first one.
We don't have an alias list_next_entry for list_first_entry?
Regards,
Christian.
Am 18.03.2018 um 22:51 schrieb Arushi Singhal:
This patch replaces list_entry with list_first_entry as it makes
Am 16.03.2018 um 08:46 schrieb Gerd Hoffmann:
A driver to let userspace turn iovecs into dma-bufs.
Use case: Allows qemu create dmabufs for the vga framebuffer or
virtio-gpu ressources. Then they can be passed around to display
those guest things on the host. To spice client for classic full
ailable, it doesn't guarantee 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 ...
a 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 ; Koenig, Christian
; dri-de...@lists.freedesktop.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH]
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 ; Koenig, Christian ;
dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org
Subject: Re: [PATC
hat so 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.or
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.
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, staged
ff-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/dr
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
--- a
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/
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
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
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.
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
evict
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
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
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
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_mut
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 a
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
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
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
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 anno
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 firs
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
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 and the
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
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
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
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
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
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
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
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
("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
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 peak
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 faul
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 gro
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
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
ac
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).
Honestly
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
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 t
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...+>\&e\)) S1 else S
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 ac
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 th
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
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 and
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
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
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 rep
sky
Sent: Friday, January 19, 2018 12:48 AM
To: linux-kernel@vger.kernel.org; linux...@kvack.org;
dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Koenig, Christian
Subject: [RFC] Per file OOM badness
Hi, this series is a revised version of an RFC sent by Christian König a few
We need to reprogram the register content during resume.
Signed-off-by: Christian König
Reported-by: Tom St Denis
---
arch/x86/pci/fixup.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index
Am 16.01.2018 um 09:28 schrieb Christoph Hellwig:
On Tue, Jan 16, 2018 at 09:22:52AM +0100, Christian König wrote:
Hi Konrad,
can you send the first patch to Linus for inclusion in 4.15 if you haven't
already done so?
It's in the 4.16 queue with a cc to stable. I guess we&#x
Hi Konrad,
can you send the first patch to Linus for inclusion in 4.15 if you
haven't already done so?
I'm still getting reports from people complaining about the error message.
Thanks,
Christian.
Am 16.01.2018 um 08:53 schrieb Christoph Hellwig:
I've pulled this into the dma-mapping for-ne
Am 11.01.2018 um 15:21 schrieb Bjorn Helgaas:
On Thu, Jan 11, 2018 at 02:23:30PM +0100, Christian König wrote:
Avoid problems with BIOS implementations which don't report all used
resources to the OS by only allocating a 256GB window directly below the
hardware limit.
For the full har
Only try to enable a 64bit window on AMD CPUs when pci=big_root_window is
specified and taint the kernel when we add the window.
v2: add documentation for the new option.
Signed-off-by: Christian König
---
Documentation/admin-guide/kernel-parameters.txt | 4
arch/x86/include/asm/pci_x86.h
igned-off-by: Christian König
---
arch/x86/pci/fixup.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index a91280da2ea1..9c1c98d7e3a7 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -662,10 +6
Am 10.01.2018 um 19:02 schrieb Bjorn Helgaas:
[+cc linux-pci, previous cc list]
On Wed, Jan 10, 2018 at 01:25:51PM +0100, Christian König wrote:
Avoid problems with BIOS implementations which don't report all used
resources to the OS by only allocating a 256GB window directly belo
Hi Arnd,
Am 10.01.2018 um 16:45 schrieb Arnd Bergmann:
14 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:1186:2: warning: ignoring return
value of 'register_shrinker', declared with attribute warn_unused_result
[-Wunused-result]
14 drivers/gpu/drm/ttm/ttm_page_alloc.c:485:2: warning: ignoring return
Am 09.01.2018 um 19:38 schrieb Bjorn Helgaas:
I don't like to add new parameters because I think it's an
unreasonable burden on users and it makes it hard for distros, but I
understand the desire to use this functionality. What would you think
of adding a "pci=big_root_window" parameter that log
Avoid problems with BIOS implementations which don't report all used
resources to the OS by only allocating a 256GB window directly below the
hardware limit.
v2: cleanup code a bit more, update comment and explain the hw limit
Signed-off-by: Christian König
---
arch/x86/pci/fixup.c
Only try to enable a 64bit window on AMD CPUs when pci=big_root_window is
specified and taint the kernel when we add the window.
Signed-off-by: Christian König
---
arch/x86/include/asm/pci_x86.h | 1 +
arch/x86/pci/common.c | 5 +
arch/x86/pci/fixup.c | 4
3 files
Acked-by: Christian König for the whole series.
Regards,
Christian.
Am 10.01.2018 um 09:09 schrieb Christoph Hellwig:
A lot of architectures have essentially identical dma_map_ops
implementations to use swiotlb. This series adds new generic
swiotlb_alloc/free helpers that take the attrs
Am 09.01.2018 um 20:18 schrieb Linus Torvalds:
On Tue, Jan 9, 2018 at 2:37 AM, Christian König
wrote:
I tested a bit with Aaro and came up with the attached patch, it adds a 16GB
guard between the end of memory and the new window for the PCIe root hub.
But I agree with you that this is just a
just ends up in a silent reboot loop.
I bisected this to:
commit fa564ad9636651fd11ec2c79c48dee844066f73a
Author: Christian König
Date: Tue Oct 24 14:40:29 2017 -0500
x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)
Hmm. That was reported to break boot earlier al
n box with the
v4.15-rc mainline Linux. It just ends up in a silent reboot loop.
I bisected this to:
commit fa564ad9636651fd11ec2c79c48dee844066f73a
Author: Christian König
Date: Tue Oct 24 14:40:29 2017 -0500
x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)
Hmm.
Am 04.01.2018 um 14:29 schrieb Christoph Hellwig:
@@ -713,6 +713,7 @@ void *
swiotlb_alloc_coherent(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags)
{
+ bool warn = !(flags & __GFP_NOWARN);
This is still wrong. __GFP_NOWARN has no meaning
: coding style fixes as suggested by Konrad
v4: make tbl_map_single static
v5: use DMA_ATTR_NO_WARN instead
Signed-off-by: Christian König
Reported-by: Mike Galbraith
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104082
CC: sta...@vger.kernel.org
---
lib/swiotlb.c | 15 +--
1 file
Am 04.01.2018 um 10:53 schrieb Christoph Hellwig:
This seems to collide with my dma direct/swiotlb series posted recently.
+++ b/lib/swiotlb.c
@@ -490,11 +490,11 @@ static void swiotlb_bounce(phys_addr_t orig_addr,
phys_addr_t tlb_addr,
}
}
-phys_addr_t swiotlb_tbl_map_single(stru
: coding style fixes as suggested by Konrad
v4: make tbl_map_single static
Signed-off-by: Christian König
Reported-by: Mike Galbraith
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104082
CC: sta...@vger.kernel.org
---
lib/swiotlb.c | 44 +---
1 file changed
: coding style fixes as suggested by Konrad
Signed-off-by: Christian König
Reported-by: Mike Galbraith
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104082
CC: sta...@vger.kernel.org
---
lib/swiotlb.c | 44 +---
1 file changed, 29 insertions(+), 15
Am 02.01.2018 um 21:51 schrieb Konrad Rzeszutek Wilk:
On Tue, Jan 02, 2018 at 01:13:58PM +0100, Christian König wrote:
[SNIP]
+
+phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
+ dma_addr_t tbl_dma_addr,
+ phys_addr_t
Am 02.01.2018 um 16:39 schrieb Chris Wilson:
Quoting Christian König (2018-01-02 12:13:58)
TTM tries to allocate coherent memory in chunks of 2MB first to improve
TLB efficiency and falls back to allocating 4K pages if that fails.
Suppress the warning when the 2MB allocations fails since there
401 - 500 of 926 matches
Mail list logo
