public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thellstrom@vmware.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	bskeggs@redhat.com, j.glisse@redhat.com, thomas@shipmail.org,
	airlied@redhat.com, airlied@linux.ie, alexdeucher@gmail.com,
	xen-devel@lists.xensource.com
Subject: Re: [PATCH] TTM DMA pool v1.8
Date: Fri, 30 Sep 2011 08:59:52 +0200	[thread overview]
Message-ID: <4E8568E8.1070800@vmware.com> (raw)
In-Reply-To: <1317328432-25620-1-git-send-email-konrad.wilk@oracle.com>

Konrad,

I'm really sorry for taking so long to review this.

I'd like to go through a couple of high-level things first before 
reviewing the coding itself.

The page_alloc_func structure looks nice, but I'd like to have it per 
ttm backend,
we would just need to make sure that the backend is alive when we alloc 
/ free pages.
The reason for this is that there may be backends that want to allocate 
dma memory running simultaneously with those who don't. When the backend 
fires up, it can determine whether to use DMA memory or not.

This also eliminates the need for patch 3/9. and is in line with patch 8/9.

2) Memory accounting: If the number DMA pages are limited in a way that 
the ttm memory global routines are not aware of. How do we handle memory 
accounting? (How do we avoid exhausting IOMMU space)?

3) Page swapping. Currently we just copy pages to shmem pages and then 
free device pages. In the future we'd probably like to insert non-dma 
pages directly into the swap cache. Is it possible to differentiate dma 
pages from pages that are directly insertable?

Thanks
Thomas



On 09/29/2011 10:33 PM, Konrad Rzeszutek Wilk wrote:
> [.. and this is what I said in v1 post]:
>
> Way back in January this patchset:
> http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
> was merged in, but pieces of it had to be reverted b/c they did not
> work properly under PowerPC, ARM, and when swapping out pages to disk.
>
> After a bit of discussion on the mailing list
> http://marc.info/?i=4D769726.2030307@shipmail.org I started working on it, but
> got waylaid by other things .. and finally I am able to post the RFC patches.
>
> There was a lot of discussion about it and I am not sure if I captured
> everybody's thoughts - if I did not - that is _not_ intentional - it has just
> been quite some time..
>
> Anyhow .. the patches explore what the "lib/dmapool.c" does - which is to have a
> DMA pool that the device has associated with. I kind of married that code
> along with drivers/gpu/drm/ttm/ttm_page_alloc.c to create a TTM DMA pool code.
> The end result is DMA pool with extra features: can do write-combine, uncached,
> writeback (and tracks them and sets back to WB when freed); tracks "cached"
> pages that don't really need to be returned to a pool; and hooks up to
> the shrinker code so that the pools can be shrunk.
>
> If you guys think this set of patches make sense  - my future plans were
>   1) Get this in large crowd of testing .. and if it works for a kernel release
>   2) to move a bulk of this in the lib/dmapool.c (I spoke with Matthew Wilcox
>      about it and he is OK as long as I don't introduce performance regressions).
>
> But before I do any of that a second set of eyes taking a look at these
> patches would be most welcome.
>
> In regards to testing, I've been running them non-stop for the last month
> (and found some issues which I've fixed up) - and been quite happy with how
> they work.
>
> Michel (thanks!) took a spin of the patches on his PowerPC and they did not
> cause any regressions (wheew).
>
> The patches are also located in a git tree:
>
>   git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v1.8
>
>   drivers/gpu/drm/nouveau/nouveau_mem.c    |    8 +-
>   drivers/gpu/drm/nouveau/nouveau_sgdma.c  |    3 +-
>   drivers/gpu/drm/radeon/radeon_device.c   |    6 +
>   drivers/gpu/drm/radeon/radeon_gart.c     |    4 +-
>   drivers/gpu/drm/radeon/radeon_ttm.c      |    3 +-
>   drivers/gpu/drm/ttm/Makefile             |    3 +
>   drivers/gpu/drm/ttm/ttm_bo.c             |    4 +-
>   drivers/gpu/drm/ttm/ttm_memory.c         |    5 +
>   drivers/gpu/drm/ttm/ttm_page_alloc.c     |   63 ++-
>   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1317 ++++++++++++++++++++++++++++++
>   drivers/gpu/drm/ttm/ttm_tt.c             |    5 +-
>   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c      |    4 +-
>   drivers/xen/swiotlb-xen.c                |    2 +-
>   include/drm/ttm/ttm_bo_driver.h          |    7 +-
>   include/drm/ttm/ttm_page_alloc.h         |  100 +++-
>   include/linux/swiotlb.h                  |    7 +-
>   lib/swiotlb.c                            |    5 +-
>   17 files changed, 1516 insertions(+), 30 deletions(-)
>    


  parent reply	other threads:[~2011-09-30  7:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-29 20:33 [PATCH] TTM DMA pool v1.8 Konrad Rzeszutek Wilk
2011-09-29 20:33 ` [PATCH 1/9] ttm/radeon/nouveau: Check the DMA address from TTM against known value Konrad Rzeszutek Wilk
2011-09-29 20:33 ` [PATCH 2/9] ttm: Introduce ttm_page_alloc_func structure Konrad Rzeszutek Wilk
2011-09-29 20:33 ` [PATCH 3/9] ttm: Pass in 'struct device' to TTM so it can do DMA API on behalf of device Konrad Rzeszutek Wilk
2011-09-29 20:33 ` [PATCH 4/9] swiotlb: Expose swiotlb_nr_tlb function to modules Konrad Rzeszutek Wilk
2011-09-29 23:49   ` FUJITA Tomonori
2011-09-29 20:33 ` [PATCH 5/9] ttm: Provide a DMA aware TTM page pool code Konrad Rzeszutek Wilk
2011-09-29 20:33 ` [PATCH 6/9] ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime Konrad Rzeszutek Wilk
2011-09-29 20:33 ` [PATCH 7/9] nouveau/radeon: Set coherent DMA mask Konrad Rzeszutek Wilk
2011-09-29 20:33 ` [PATCH 8/9] ttm/tt: Move ttm_tt_set_page_caching implementation in TTM page pool code Konrad Rzeszutek Wilk
2011-09-29 20:33 ` [PATCH 9/9] ttm/dma: Implement set_page_caching implementation in the TTM DMA " Konrad Rzeszutek Wilk
2011-09-30  6:59 ` Thomas Hellstrom [this message]
2011-09-30 14:09   ` [PATCH] TTM DMA pool v1.8 Konrad Rzeszutek Wilk
2011-10-03 16:35     ` Thomas Hellstrom
2011-10-03 16:46       ` Konrad Rzeszutek Wilk
2011-10-03 16:56         ` Thomas Hellstrom

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=4E8568E8.1070800@vmware.com \
    --to=thellstrom@vmware.com \
    --cc=airlied@linux.ie \
    --cc=airlied@redhat.com \
    --cc=alexdeucher@gmail.com \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas@shipmail.org \
    --cc=xen-devel@lists.xensource.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox