On 2/2/18 10:59 AM, Eric Dumazet wrote:
> On Fri, Feb 2, 2018 at 10:53 AM, Christoph Hellwig wrote:
>> I've got patches pending to replace all that code with
>> dma_direct_alloc, which will do the right thing. They were
>> submitted for 4.16, and I will resend t
On Fri, Jan 31, 2020 at 9:43 AM Robin Murphy wrote:
>
> On 31/01/2020 2:42 pm, Eric Dumazet wrote:
> > On Fri, Jan 31, 2020 at 4:30 AM Robin Murphy wrote:
> >>
> >> ...and when that represents ~5% of the total system RAM it is a *lot*
> >> less reasonable t
On Fri, Jan 31, 2020 at 4:30 AM Robin Murphy wrote:
>
> ...and when that represents ~5% of the total system RAM it is a *lot*
> less reasonable than even 12KB. As I said, it's great to make a debug
> option more efficient such that what it observes is more representative
> of the non-debug behavio
On Thu, Jan 30, 2020 at 3:46 PM Robin Murphy wrote:
>
> Hi Eric,
>
> On 2020-01-30 7:10 pm, Eric Dumazet via iommu wrote:
> > Increasing the size of dma_entry_hash size by 327680 bytes
> > has reached some bootloaders limitations.
>
> [ That might warrant some furth
replacement.
Tested on a 40Gbit mlx4 NIC, with 16 RX queues and about
1,000,000 replacements per second.
Signed-off-by: Eric Dumazet
Cc: Christoph Hellwig
---
kernel/dma/debug.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
: 5e76f564572b ("dma-debug: increase HASH_SIZE")
Signed-off-by: Eric Dumazet
Reported-by: Geert Uytterhoeven
Cc: Christoph Hellwig
---
kernel/dma/debug.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/deb
sharing in the first place seems easy.
We should attempt the atomic_cmpxchg() no more than 100 times
per second. Adding an atomic_read() will keep the cache
line mostly shared.
This false sharing came with commit 9a005a800ae8
("iommu/iova: Add flush timer").
Signed-off-by: Eric Dumazet
Cc:
On Fri, Feb 2, 2018 at 10:53 AM, Christoph Hellwig wrote:
> I've got patches pending to replace all that code with
> dma_direct_alloc, which will do the right thing. They were
> submitted for 4.16, and I will resend them after -rc1.
I see, thanks Christoph !
_
From: Eric Dumazet
Some devices (like mlx4) try hard to allocate memory on selected
NUMA node, but it turns out intel_alloc_coherent() is not NUMA
aware yet.
Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c
gets this right.
Signed-off-by: Eric Dumazet
Cc: Benjamin Serebrin
On Wed, 2018-01-31 at 14:45 -0800, Eric Dumazet wrote:
> From: Eric Dumazet
>
> Some devices (like mlx4) try hard to allocate memory on selected
> NUMA node, but it turns out intel_alloc_coherent() is not NUMA
> aware yet.
>
> Note that dma_generic_alloc_coherent() in arch
From: Eric Dumazet
Some devices (like mlx4) try hard to allocate memory on selected
NUMA node, but it turns out intel_alloc_coherent() is not NUMA
aware yet.
Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c
gets this right.
Signed-off-by: Eric Dumazet
Cc: Benjamin Serebrin
11 matches
Mail list logo
