On Fri, Sep 26, 2014 at 8:34 AM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> wrote: > On 09/26/2014 02:28 PM, Rob Clark wrote: >> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> wrote: >>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote: >>>> On Fri, 26 Sep 2014 09:15:57 +0200 >>>> Thomas Hellstrom <thellstrom@xxxxxxxxxx> 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. > > But can the DMA subsystem or more specifically dma_alloc_coherent() > really guarantee such things? Isn't it better for such devices to use > CMA directly? Well, I was thinking more specifically about a use-case that was mentioned several times during the early CMA discussions, about video decoders/encoders which needed Y and UV split across memory banks to achieve sufficient bandwidth. I assume they must use CMA directly for this (since they'd need multiple pools per device), but not really 100% sure about that. So perhaps, yeah, if you shunt order 0 allocations away from CMA at the DMA layer, maybe it is ok. If there actually is a valid use-case for CMA on sane hardware, then maybe this is the better way, and let the insane hw folks hack around it. (plus, well, the use-case I was mentioning isn't really about order 0 allocations anyway) BR, -R > /Thomas > > >> >> Seems like disabling CMA on x86 (where it should be unneeded) is the >> better way, IMO >> >> BR, >> -R >> >> >>> /Thomas >>> >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@xxxxxxxxxxxxxxxxxxxxx >>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/dri-devel&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=Uz7JXDXYXp4RlLs7G6qxMQlhOOT0trW3l78xpKg6Ass%3D%0A&s=50d6b7b3bfd093c93a228437a3d4414e49b4de817657c49c35154a115a5c2188 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
