linux-kernel - Re: [PATCH] TTM DMA pool v2.1

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111031220557.GD3036@homer.localdomain>
Date:	Mon, 31 Oct 2011 18:05:57 -0400
From:	Jerome Glisse <j.glisse@...il.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	thellstrom@...are.com, thomas@...pmail.org, airlied@...hat.com,
	xen-devel@...ts.xensource.com, j.glisse@...hat.com,
	bskeggs@...hat.com
Subject: Re: [PATCH] TTM DMA pool v2.1

On Wed, Oct 19, 2011 at 06:19:21PM -0400, 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:
> 

Reviewed the patch series, looks good, already sent comment on
one of the patch. I am on the same side of Thomas for dma stuff,
lately i have been working on GPU virtual memory address space
and i believe having driver allocating the ttm_tt and merging
more stuff in the backend make sense, after all the backend
has better knowledge on both cache preference and dma mask.

So far my idea is to merge ttm_tt & ttm_backend, simplify the
backend function to bind/unbind/destroy where bind is
responsible to allocate or not a ttm_tt and pages that goes
along with it. I will try to sketch up patches for all this
in next few days.

Reviewed-by: Jerome Glisse <jglisse@...hat.com>

Cheers,
Jerome Glisse
--
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/