-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/26/2014 08:28 AM, Rob Clark wrote:
On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom thellstrom@vmware.com wrote:
On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
On Fri, 26 Sep 2014 09:15:57 +0200 Thomas Hellstrom thellstrom@vmware.com wrote:
On 09/26/2014 01:52 AM, Peter Hurley wrote:
On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
There are six ttm patches queued for 3.16.4:
drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch
Thanks for info, Chuck.
Unfortunately, none of these fix TTM dma allocation doing CMA dma allocation, which is the root problem.
Regards, Peter Hurley
The problem is not really in TTM but in CMA, There was a guy offering to fix this in the CMA code but I guess he didn't probably because he didn't receive any feedback.
Yeah, the "solution" to this problem seems to be "don't enable CMA on x86". Maybe it should even be disabled in the config system.
Or, as previously suggested, don't use CMA for order 0 (single page) allocations....
On devices that actually need CMA pools to arrange for memory to be in certain ranges, I think you probably do want to have order 0 pages come from the CMA pool.
Seems like disabling CMA on x86 (where it should be unneeded) is the better way, IMO
CMA has its uses on x86. For example, CMA is used to allocate 1GB huge pages.
There may also be people with devices that do not scatter-gather, and need a large physically contiguous buffer, though there should be relatively few of those on x86.
I suspect it makes most sense to do DMA allocations up to PAGE_ORDER through the normal allocator on x86, and only invoking CMA for larger allocations.
- -- All rights reversed