Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible

2018-04-20 Thread Christoph Hellwig
On Fri, Apr 20, 2018 at 11:58:58AM +0200, Takashi Iwai wrote: > It's because it's written on the tree with another fix patch I sent > beforehand ("[PATCH 1/2] dma-direct: Don't repeat allocation for no-op > GFP_DMA"). > > Could you check that one at first? I'm fine to rebase and resubmit > this

Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible

2018-04-20 Thread Takashi Iwai
On Fri, 20 Apr 2018 11:47:02 +0200, Christoph Hellwig wrote: > > On Mon, Apr 16, 2018 at 05:18:19PM +0200, Takashi Iwai wrote: > > As the recent swiotlb bug revealed, we seem to have given up the > > direct DMA allocation too early and felt back to swiotlb allocation. > > The reason is that

Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible

2018-04-20 Thread Christoph Hellwig
On Mon, Apr 16, 2018 at 05:18:19PM +0200, Takashi Iwai wrote: > As the recent swiotlb bug revealed, we seem to have given up the > direct DMA allocation too early and felt back to swiotlb allocation. > The reason is that swiotlb allocator expected that dma_direct_alloc() > would try harder to get

[PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible

2018-04-16 Thread Takashi Iwai
As the recent swiotlb bug revealed, we seem to have given up the direct DMA allocation too early and felt back to swiotlb allocation. The reason is that swiotlb allocator expected that dma_direct_alloc() would try harder to get pages even below 64bit DMA mask with GFP_DMA32, but the function