linux-kernel - [RFC PATCH] TTM DMA pool v1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1314206224-15304-1-git-send-email-konrad.wilk@oracle.com>
Date:	Wed, 24 Aug 2011 13:16:58 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	bskeggs@...hat.com, j.glisse@...hat.com, thomas@...pmail.org,
	airlied@...hat.com, airlied@...ux.ie, alexdeucher@...il.com
Subject: [RFC PATCH] TTM DMA pool v1

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 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).

As I mentioned, in the past, the patches I introduced broke certain scenarios
so I've been running compile/runtime tests to make sure I don't repeat my past
mistakes.  Both nouveau and radeon - IGP, PCI-e, and with various IOMMUs -
Calgary, GART, SWIOTLB, Xen SWIOTLB, AMD-VI work correctly (still need to test
Intel VT-d).

My PowerPC has issues with booting a virgin 3.0 kernel (something about
"ELF image not correct") so I don't have that yet covered.

The patches are also located in a git tree:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/ttm.dma_pool.v1.5

And the full diffstat is:

 drivers/gpu/drm/nouveau/nouveau_mem.c    |    3 +-
 drivers/gpu/drm/nouveau/nouveau_sgdma.c  |    3 +-
 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 | 1311 ++++++++++++++++++++++++++++++
 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 +-
 16 files changed, 1499 insertions(+), 30 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/