Hi!
Just wanted to share some thoughts about CMA, TTM and the problems with conflicting mappings.
1) CMA seems to be a nice way to handle the problem with contigous pages, although it seems Arnd has some concerns. It would be nice to here about those. Some thoughts:
a) It seems fairly straightforward to interface CMA with TTM. The benefit would be that CMA could ask TTM at any time (using a shrinker callback) to release its contigous pages, and TTM would do so once the GPU is finished with them (unless of course they are used with a pinned buffer object, like a scanout buffer). CMA would need to be extended with a small API to create / free a contigous range and to actually populate that range with pages.
b) DRM, TTM and it seems CMA all need a range allocator. There is a reasonable implementation in drm_mm.c, which since the original implementation has seen a fair bit of improvement. Should we try to move that to linux/lib ?
c) Could the CMA technique be used also to keep a pool of pages that are unmapped from the linear kernel map? Essentially a range of HIGHMEM pages? The benefit compared to just having a pool of HIGHMEM pages by itself would be that the graphics subsystem would have priority over normal system use (moving out movable contents), and could use these pages with nonstandard caching attribute maps if needed. If this is considered a good idea, we could perhaps consider placing the default CMA region in HIGHMEM.
/Thomas
On Tue, May 10, 2011 at 12:55 PM, Thomas Hellstrom thellstrom@vmware.com wrote:
b) DRM, TTM and it seems CMA all need a range allocator. There is a reasonable implementation in drm_mm.c, which since the original implementation has seen a fair bit of improvement. Should we try to move that to linux/lib ?
V4L2 and ALSA and what else also need contigous memory buffers, so I think the world would be a better place if the entire business of contigous allocation, buffer pinning and passing could be made abstract from the stuff that is using it, CMA, TTM and GEM alike.
Just my €0.01.. Linus Walleij
linaro-mm-sig@lists.linaro.org