From: Thomas Hellstrom <thellstrom@vmware.com> To: Rob Clark <robdclark@gmail.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 14:34:32 +0200 [thread overview] Message-ID: <54255D58.1040802@vmware.com> (raw) In-Reply-To: <CAF6AEGvOkPq5LQR76-VbspYyCvUxL1=W-dLc4g_aWX2wkUmRpg@mail.gmail.com> 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? /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: Thomas Hellstrom <thellstrom@vmware.com> To: Rob Clark <robdclark@gmail.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 14:34:32 +0200 [thread overview] Message-ID: <54255D58.1040802@vmware.com> (raw) In-Reply-To: <CAF6AEGvOkPq5LQR76-VbspYyCvUxL1=W-dLc4g_aWX2wkUmRpg@mail.gmail.com> 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? /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 12:34 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 [this message] 2014-09-26 12:34 ` Thomas Hellstrom 2014-09-26 13:40 ` Rob Clark 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=54255D58.1040802@vmware.com \ --to=thellstrom@vmware.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=robdclark@gmail.com \ --cc=shli@kernel.org \ --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.