LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Jaewon Kim <jaewon31.kim@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: gregkh@linuxfoundation.org, m.szyprowski@samsung.com,
	linux-mm@kvack.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Jaewon Kim <jaewon31.kim@samsung.com>,
	ytk.lee@samsung.com
Subject: Re: [RFC PATCH] usb: host: xhci: allow __GFP_FS in dma allocation
Date: Sat, 18 May 2019 10:53:03 +0900
Message-ID: <CAJrd-UuCMpuSDh6Sx24=aesK38XSB5ys2pHCT4K-O0VSj4ewkA@mail.gmail.com> (raw)
In-Reply-To: <20190517163420.GG31704@bombadil.infradead.org>

Thank you for your comment.

In ARM64 architecture, default CMA region is commonly activated and it
could be used
if no specific memory region is defined. The USB driver in my platform
also uses the
default CMA region as DMA allocation. If using the CMA to do DMA
allocation is improper,
then do you think that the USB driver for my platform should be
changed not to use CMA?

According to my understanding, in CONFIG_DMA_CMA on both v4.14 and v5.0,
__GFP_DIRECT_RECLAIM will try CMA allocation first instead of normal
buddy allocation.
Then it will get default CMA region through dev_get_cma_area API.
Please refer to
dev_get_cma_area code below though I am using v4.14 for my platform.

git show v5.0:include/linux/dma-contiguous.h
 61 #ifdef CONFIG_DMA_CMA
 62
 63 extern struct cma *dma_contiguous_default_area;
 64
 65 static inline struct cma *dev_get_cma_area(struct device *dev)
 66 {
 67         if (dev && dev->cma_area)
 68                 return dev->cma_area;
 69         return dma_contiguous_default_area;
 70 }

Thank you

2019년 5월 18일 (토) 오전 1:34, Matthew Wilcox <willy@infradead.org>님이 작성:
>
> On Sat, May 18, 2019 at 01:02:28AM +0900, Jaewon Kim wrote:
> > Hello I don't have enough knowledge on USB core but I've wondered
> > why GFP_NOIO has been used in xhci_alloc_dev for
> > xhci_alloc_virt_device. I found commit ("a6d940dd759b xhci: Use
> > GFP_NOIO during device reset"). But can we just change GFP_NOIO
> > to __GFP_RECLAIM | __GFP_FS ?
>
> No.  __GFP_FS implies __GFP_IO; you can't set __GFP_FS and clear __GFP_IO.
>
> It seems like the problem you have is using the CMA to do DMA allocation.
> Why would you do such a thing?
>
> > Please refer to below case.
> >
> > I got a report from Lee YongTaek <ytk.lee@samsung.com> that the
> > xhci_alloc_virt_device was too slow over 2 seconds only for one page
> > allocation.
> >
> > 1) It was because kernel version was v4.14 and DMA allocation was
> > done from CMA(Contiguous Memory Allocator) where CMA region was
> > almost filled with file page and  CMA passes GFP down to page
> > isolation. And the page isolation only allows file page isolation only to
> > requests having __GFP_FS.
> >
> > 2) Historically CMA was changed at v4.19 to use GFP_KERNEL
> > regardless of GFP passed to  DMA allocation through the
> > commit 6518202970c1 "(mm/cma: remove unsupported gfp_mask
> > parameter from cma_alloc()".
> >
> > I think pre v4.19 the xhci_alloc_virt_device could be very slow
> > depending on CMA situation but free to USB deadlock issue. But as of
> > v4.19, I think, it will be fast but can face the deadlock issue.
> > Consequently I think to meet the both cases, I think USB can pass
> > __GFP_FS without __GFP_IO.
> >
> > If __GFP_FS is passed from USB core, of course, the CMA patch also
> > need to be changed to pass GFP.
>
>

  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-17 16:02 Jaewon Kim
2019-05-17 16:34 ` Matthew Wilcox
2019-05-18  1:53   ` Jaewon Kim [this message]
2019-05-20  5:56 ` Christoph Hellwig
2019-05-20  9:09   ` Oliver Neukum
2019-05-20 10:12     ` Christoph Hellwig
2019-05-20 14:16       ` Alan Stern
2019-05-20 14:23         ` Christoph Hellwig
2019-05-21  8:54           ` Oliver Neukum
2019-05-21 13:27             ` Christoph Hellwig
2019-05-21 13:11         ` Oliver Neukum
2019-05-21 14:00           ` Alan Stern
2019-05-22  6:31             ` Oliver Neukum
2019-05-22 14:56               ` Alan Stern
2019-05-22 20:47                 ` Oliver Neukum
2019-05-23 14:01                   ` Alan Stern
2019-05-28 12:34                     ` Oliver Neukum
2019-05-28 14:25                       ` Alan Stern
2019-05-23 12:32   ` Oliver Neukum
2019-05-23 16:35     ` Christoph Hellwig

Reply instructions:

You may reply publically 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='CAJrd-UuCMpuSDh6Sx24=aesK38XSB5ys2pHCT4K-O0VSj4ewkA@mail.gmail.com' \
    --to=jaewon31.kim@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jaewon31.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=willy@infradead.org \
    --cc=ytk.lee@samsung.com \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox