All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible
Date: Fri, 20 Apr 2018 11:47:02 +0200	[thread overview]
Message-ID: <20180420094702.GA6530@lst.de> (raw)
In-Reply-To: <20180416151819.27520-1-tiwai-l3A5Bk7waGM@public.gmane.org>

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 pages even below 64bit DMA mask with
> GFP_DMA32, but the function doesn't do that but only deals with
> GFP_DMA case.
> 
> This patch adds a similar fallback reallocation with GFP_DMA32 as
> we've done with GFP_DMA.  The condition is that the coherent mask is
> smaller than 64bit (i.e. some address limitation), and neither GFP_DMA
> nor GFP_DMA32 is set beforehand.
> 
> Signed-off-by: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
> 
> ---
> 
> This is a resend of a test patch included in the previous thread
> ("swiotlb: Fix unexpected swiotlb_alloc_coherent() failures").

I like the patch, but as-is it doesn't apply.  Can you resend it against
latest Linus' tree?

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: Christoph Hellwig <hch@lst.de>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible
Date: Fri, 20 Apr 2018 11:47:02 +0200	[thread overview]
Message-ID: <20180420094702.GA6530@lst.de> (raw)
In-Reply-To: <20180416151819.27520-1-tiwai@suse.de>

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 pages even below 64bit DMA mask with
> GFP_DMA32, but the function doesn't do that but only deals with
> GFP_DMA case.
> 
> This patch adds a similar fallback reallocation with GFP_DMA32 as
> we've done with GFP_DMA.  The condition is that the coherent mask is
> smaller than 64bit (i.e. some address limitation), and neither GFP_DMA
> nor GFP_DMA32 is set beforehand.
> 
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> 
> ---
> 
> This is a resend of a test patch included in the previous thread
> ("swiotlb: Fix unexpected swiotlb_alloc_coherent() failures").

I like the patch, but as-is it doesn't apply.  Can you resend it against
latest Linus' tree?

  parent reply	other threads:[~2018-04-20  9:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16 15:18 [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible Takashi Iwai
     [not found] ` <20180416151819.27520-1-tiwai-l3A5Bk7waGM@public.gmane.org>
2018-04-20  9:47   ` Christoph Hellwig [this message]
2018-04-20  9:47     ` Christoph Hellwig
     [not found]     ` <20180420094702.GA6530-jcswGhMUV9g@public.gmane.org>
2018-04-20  9:58       ` Takashi Iwai
2018-04-20  9:58         ` Takashi Iwai
     [not found]         ` <s5hfu3qw659.wl-tiwai-l3A5Bk7waGM@public.gmane.org>
2018-04-20 10:06           ` Christoph Hellwig
2018-04-20 10:06             ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180420094702.GA6530@lst.de \
    --to=hch-jcswghmuv9g@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=tiwai-l3A5Bk7waGM@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.