From: Rob Clark <robdclark@gmail.com> To: Thomas Hellstrom <thellstrom@vmware.com> Cc: Chuck Ebbert <cebbert.lkml@gmail.com>, Rik van Riel <riel@redhat.com>, Peter Hurley <peter@hurleysoftware.com>, Linus Torvalds <torvalds@linux-foundation.org>, Hugh Dickens <hughd@google.com>, Linux kernel <linux-kernel@vger.kernel.org>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, linux-mm <linux-mm@kvack.org>, Mel Gorman <mgorman@suse.de>, Andrew Morton <akpm@linux-foundation.org>, Shaohua Li <shli@kernel.org>, Ingo Molnar <mingo@kernel.org> Subject: Re: page allocator bug in 3.16? Date: Fri, 26 Sep 2014 09:40:03 -0400 [thread overview] Message-ID: <CAF6AEGteJcYdQekMPW3vc9S6_=URqJus7-Faq-RrdTp_ETN1eQ@mail.gmail.com> (raw) In-Reply-To: <54255D58.1040802@vmware.com> On Fri, Sep 26, 2014 at 8:34 AM, Thomas Hellstrom <thellstrom@vmware.com> wrote: > On 09/26/2014 02:28 PM, 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. > > 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@lists.freedesktop.org >>> 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com> To: Thomas Hellstrom <thellstrom@vmware.com> Cc: Chuck Ebbert <cebbert.lkml@gmail.com>, Rik van Riel <riel@redhat.com>, Peter Hurley <peter@hurleysoftware.com>, Linus Torvalds <torvalds@linux-foundation.org>, Hugh Dickens <hughd@google.com>, Linux kernel <linux-kernel@vger.kernel.org>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, linux-mm <linux-mm@kvack.org>, Mel Gorman <mgorman@suse.de>, Andrew Morton <akpm@linux-foundation.org>, Shaohua Li <shli@kernel.org>, Ingo Molnar <mingo@kernel.org> Subject: Re: page allocator bug in 3.16? Date: Fri, 26 Sep 2014 09:40:03 -0400 [thread overview] Message-ID: <CAF6AEGteJcYdQekMPW3vc9S6_=URqJus7-Faq-RrdTp_ETN1eQ@mail.gmail.com> (raw) In-Reply-To: <54255D58.1040802@vmware.com> On Fri, Sep 26, 2014 at 8:34 AM, Thomas Hellstrom <thellstrom@vmware.com> wrote: > On 09/26/2014 02:28 PM, 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. > > 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@lists.freedesktop.org >>> 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 > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-09-26 13:40 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-25 18:55 page allocator bug in 3.16? Peter Hurley 2014-09-25 18:55 ` Peter Hurley 2014-09-25 18:55 ` Peter Hurley 2014-09-25 19:34 ` Maarten Lankhorst 2014-09-25 19:34 ` Maarten Lankhorst 2014-09-25 19:34 ` Maarten Lankhorst 2014-09-25 19:35 ` Chuck Ebbert 2014-09-25 19:35 ` Chuck Ebbert 2014-09-25 23:52 ` Peter Hurley 2014-09-25 23:52 ` Peter Hurley 2014-09-26 7:15 ` Thomas Hellstrom 2014-09-26 7:15 ` Thomas Hellstrom 2014-09-26 7:15 ` Thomas Hellstrom 2014-09-26 10:40 ` Chuck Ebbert 2014-09-26 10:40 ` Chuck Ebbert 2014-09-26 10:45 ` Thomas Hellstrom 2014-09-26 10:45 ` Thomas Hellstrom 2014-09-26 12:28 ` Rob Clark 2014-09-26 12:28 ` Rob Clark 2014-09-26 12:28 ` Rob Clark 2014-09-26 12:34 ` Thomas Hellstrom 2014-09-26 12:34 ` Thomas Hellstrom 2014-09-26 13:40 ` Rob Clark [this message] 2014-09-26 13:40 ` Rob Clark 2014-09-26 12:40 ` Rik van Riel 2014-09-26 12:40 ` Rik van Riel 2014-09-26 14:10 ` Peter Hurley 2014-09-26 14:10 ` Peter Hurley 2014-09-26 14:10 ` Peter Hurley 2014-09-26 15:12 ` Leann Ogasawara 2014-09-26 15:12 ` Leann Ogasawara 2014-09-27 14:15 ` Peter Hurley 2014-09-27 14:15 ` Peter Hurley 2014-09-25 20:33 ` Alex Deucher 2014-09-25 20:33 ` Alex Deucher 2014-09-25 21:10 ` Peter Hurley 2014-09-25 21:10 ` Peter Hurley 2014-10-01 9:26 ` Maarten Lankhorst 2014-10-01 9:26 ` Maarten Lankhorst 2014-09-25 20:36 ` Peter Hurley 2014-09-25 20:36 ` Peter Hurley 2014-09-25 20:36 ` Peter Hurley
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAF6AEGteJcYdQekMPW3vc9S6_=URqJus7-Faq-RrdTp_ETN1eQ@mail.gmail.com' \ --to=robdclark@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=cebbert.lkml@gmail.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=hughd@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=mingo@kernel.org \ --cc=peter@hurleysoftware.com \ --cc=riel@redhat.com \ --cc=shli@kernel.org \ --cc=thellstrom@vmware.com \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.