On Wed, Aug 01, 2018 at 10:09:06PM -0400, Rich Felker wrote:
> On Tue, Jul 31, 2018 at 09:24:13AM +0200, Christoph Hellwig wrote:
> > On Tue, Jul 31, 2018 at 03:06:13PM +0900, Yoshinori Sato wrote:
> > > On Wed, 25 Jul 2018 18:40:38 +0900,
> > > Christoph Hellwig wrote:
> > > >
> > > > Hi all,
> >
On Thu, Aug 02, 2018 at 04:24:22AM +, Tian, Kevin wrote:
> Date: Thu, 2 Aug 2018 04:24:22 +
> From: "Tian, Kevin"
> To: Kenneth Lee
> CC: Kenneth Lee , Jonathan Corbet ,
> Herbert Xu , "David S . Miller"
> , Joerg Roedel , Alex Williamson
> , Hao Fang , Zhou Wang
> , Zaibo Xu , Philip
On Thu, Aug 2, 2018 at 3:49 AM Kuninori Morimoto
wrote:
> From: Kuninori Morimoto
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In per
> One motivation I guess, is that most accelerators lack of a
> well-abstracted high level APIs similar to GPU side (e.g. OpenCL
> clearly defines Shared Virtual Memory models). VFIO mdev
> might be an alternative common interface to enable SVA usages
> on various accelerators...
SVA is not IMH
On Thu, 2 Aug 2018 15:34:40 +0800
Kenneth Lee wrote:
> On Thu, Aug 02, 2018 at 04:24:22AM +, Tian, Kevin wrote:
> > > From: Kenneth Lee [mailto:liguo...@hisilicon.com]
> > > Sent: Thursday, August 2, 2018 11:47 AM
> > >
> > > >
> > > > > From: Kenneth Lee
> > > > > Sent: Wednesday, Augu
Returning NULL from get_arch_dma_ops makes all DMA mapping routines
retourn sensible errors, so remove the dummy ops.
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/dma-mapping.h | 4 +-
arch/arm64/mm/dma-mapping.c | 92
2 files changed, 1 inse
Hi,
On 2018/8/2 18:10, Alan Cox wrote:
One motivation I guess, is that most accelerators lack of a
well-abstracted high level APIs similar to GPU side (e.g. OpenCL
clearly defines Shared Virtual Memory models). VFIO mdev
might be an alternative common interface to enable SVA usages
on various ac
On 02/08/18 13:13, Christoph Hellwig wrote:
Returning NULL from get_arch_dma_ops makes all DMA mapping routines
retourn sensible errors, so remove the dummy ops.
Does it? AFAICS all of the non-optional callbacks will still either
BUG_ON(!ops) or blindly dereference the null pointer. Have I los
On Thu, Aug 02, 2018 at 01:49:39AM +, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Simon Horman
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/
On Thu, Aug 02, 2018 at 01:32:17PM +0100, Robin Murphy wrote:
> On 02/08/18 13:13, Christoph Hellwig wrote:
>> Returning NULL from get_arch_dma_ops makes all DMA mapping routines
>> retourn sensible errors, so remove the dummy ops.
>
> Does it? AFAICS all of the non-optional callbacks will still ei
On Thu, Aug 02, 2018 at 12:05:57PM +0800, Kenneth Lee wrote:
> On Thu, Aug 02, 2018 at 02:33:12AM +, Tian, Kevin wrote:
> > Date: Thu, 2 Aug 2018 02:33:12 +
> > > From: Jerome Glisse
> > > On Wed, Aug 01, 2018 at 06:22:14PM +0800, Kenneth Lee wrote:
> > > > From: Kenneth Lee
> > > >
> > >
On Thu, Aug 02, 2018 at 11:10:00AM +0100, Alan Cox wrote:
> > One motivation I guess, is that most accelerators lack of a
> > well-abstracted high level APIs similar to GPU side (e.g. OpenCL
> > clearly defines Shared Virtual Memory models). VFIO mdev
> > might be an alternative common interface
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
> On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
> > On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
> > > On 27/07/18 15:10, Dmitry Osipenko wrote:
> > > >On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
>
On Thu, 2 Aug 2018 10:35:28 +0200
Cornelia Huck wrote:
> On Thu, 2 Aug 2018 15:34:40 +0800
> Kenneth Lee wrote:
>
> > On Thu, Aug 02, 2018 at 04:24:22AM +, Tian, Kevin wrote:
>
> > > > From: Kenneth Lee [mailto:liguo...@hisilicon.com]
> > > > Sent: Thursday, August 2, 2018 11:47 AM
> > >
Major changes since v1:
*) Replaced the red-black tree with virt_to_page(), which takes us to
O(n) instead of O(n * log n). The mpt3sas benchmarks only improved a
little though (18 ms -> 17 ms on alloc and 19 ms -> 15 ms on free).
*) Eliminated struct dma_page. dmapool private data are now stor
Fix the boundary comparison when constructing the list of free blocks
for the case that 'size' is a power of two. Since 'boundary' is also a
power of two, that would make 'boundary' a multiple of 'size', in which
case a single block would never cross the boundary. This bug would
cause some of the
Remove code duplication in error messages. It is now safe to pas a NULL
dev to dev_err(), so the checks to avoid doing so are no longer
necessary.
Example:
Error message with dev != NULL:
mpt3sas :02:00.0: dma_pool_destroy chain pool, (ptrval) busy
Same error message with dev == N
Remove a small amount of code duplication between dma_pool_destroy() and
pool_free_page() in preparation for adding more code without having to
duplicate it. No functional changes.
Signed-off-by: Tony Battersby
---
--- linux/mm/dmapool.c.orig 2018-08-02 09:59:15.0 -0400
+++ linux/mm/
dma_pool_alloc() scales poorly when allocating a large number of pages
because it does a linear scan of all previously-allocated pages before
allocating a new one. Improve its scalability by maintaining a separate
list of pages that have free blocks ready to (re)allocate. In big O
notation, this
Rename fields in 'struct dma_page' in preparation for moving them into
'struct page'. No functional changes.
in_use -> dma_in_use
offset -> dma_free_o
Signed-off-by: Tony Battersby
---
--- linux/mm/dmapool.c.orig 2018-08-02 10:03:46.0 -0400
+++ linux/mm/dmapool.c 2018-08-02 10:06:3
dma_pool_free() scales poorly when the pool contains many pages because
pool_find_page() does a linear scan of all allocated pages. Improve its
scalability by replacing the linear scan with virt_to_page() and storing
dmapool private data directly in 'struct page', thereby eliminating
'struct dma_p
Prevent a possible endless loop with DMAPOOL_DEBUG enabled if a buggy
driver corrupts DMA pool memory.
Signed-off-by: Tony Battersby
---
--- linux/mm/dmapool.c.orig 2018-08-02 10:14:25.0 -0400
+++ linux/mm/dmapool.c 2018-08-02 10:16:17.0 -0400
@@ -449,16 +449,35 @@ void dma_p
This is my attempt to shrink 'dma_free_o' and 'dma_in_use' in 'struct
page' (originally 'offset' and 'in_use' in 'struct dma_page') to 16-bit
so that it is unnecessary to use the '_mapcount' field of 'struct
page'. However, it adds complexity and makes allocating and freeing up
to 20% slower for l
Replace chain_dma_pool with direct calls to dma_alloc_coherent() and
dma_free_coherent(). Since the chain lookup can involve hundreds of
thousands of allocations, it is worthwile to avoid the overhead of the
dma_pool API.
Signed-off-by: Tony Battersby
---
No changes since v1.
The original code
On Thu, Aug 02, 2018 at 03:58:40PM -0400, Tony Battersby wrote:
> @@ -339,11 +360,16 @@ void *dma_pool_alloc(struct dma_pool *po
>
> spin_lock_irqsave(&pool->lock, flags);
>
> - list_add(&page->page_list, &pool->page_list);
> + list_add(&page->dma_list, &pool->page_list[POOL_AVAIL
On Thu, Aug 02, 2018 at 03:59:15PM -0400, Tony Battersby wrote:
> Rename fields in 'struct dma_page' in preparation for moving them into
> 'struct page'. No functional changes.
>
> in_use -> dma_in_use
> offset -> dma_free_o
I don't like dma_free_o. dma_free_off is OK by me.
___
On Thu, Aug 02, 2018 at 04:01:12PM -0400, Tony Battersby wrote:
> This is my attempt to shrink 'dma_free_o' and 'dma_in_use' in 'struct
> page' (originally 'offset' and 'in_use' in 'struct dma_page') to 16-bit
> so that it is unnecessary to use the '_mapcount' field of 'struct
> page'. However, it
On Thu, Aug 02, 2018 at 10:22:43AM -0400, Jerome Glisse wrote:
> Date: Thu, 2 Aug 2018 10:22:43 -0400
> From: Jerome Glisse
> To: Kenneth Lee
> CC: "Tian, Kevin" , Hao Fang ,
> Alex Williamson , Herbert Xu
> , "k...@vger.kernel.org"
> , Jonathan Corbet , Greg
> Kroah-Hartman , Zaibo Xu ,
> "
28 matches
Mail list logo
