From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by kanga.kvack.org (Postfix) with ESMTP id 9FBCB6B009C for ; Tue, 11 Mar 2014 10:02:55 -0400 (EDT) Received: by mail-ob0-f175.google.com with SMTP id uy5so8528434obc.34 for ; Tue, 11 Mar 2014 07:02:55 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [2607:f8b0:4003:c02::22f]) by mx.google.com with ESMTPS id sp3si24270958obb.134.2014.03.11.07.02.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Mar 2014 07:02:54 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id i11so8638840oag.34 for ; Tue, 11 Mar 2014 07:02:54 -0700 (PDT) MIME-Version: 1.0 From: Ramakrishnan Muthukrishnan Date: Tue, 11 Mar 2014 19:32:34 +0530 Message-ID: Subject: cma: alloc_contig_range test_pages_isolated .. failed Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Hello linux-mm hackers, We have a TI OMAP4 based system running 3.4 kernel. OMAP4 has got 2 M3 processors which is used for some media tasks. During bootup, the M3 firmware is loaded and it used CMA to allocate 3 regions for DMA, as seen by these logs: [ 0.000000] cma: dma_declare_contiguous(size a400000, base 99000000, limit 00000000) [ 0.000000] cma: CMA: reserved 168 MiB at 99000000 [ 0.000000] cma: dma_declare_contiguous(size 2000000, base 00000000, limit 00000000) [ 0.000000] cma: CMA: reserved 32 MiB at ad800000 [ 0.000000] cma: dma_contiguous_reserve(limit af800000) [ 0.000000] cma: dma_contiguous_reserve: reserving 16 MiB for global area [ 0.000000] cma: dma_declare_contiguous(size 1000000, base 00000000, limit af800000) [ 0.000000] cma: CMA: reserved 16 MiB at ac000000 [ 0.243652] cma: cma_init_reserved_areas() [ 0.243682] cma: cma_create_area(base 00099000, count a800) [ 0.253417] cma: cma_create_area: returned ed0ee400 [...] We observed that if we reboot a system without unmounting the file systems (like in abrupt power off..etc), after the fresh reboot, the file system checks are performed, the firmware load is delayed by ~4 seconds (compared to the one without fsck) and then we see the following in the kernel bootup logs: [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) failed [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) failed [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) failed [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) failed [ 26.875213] rproc remoteproc0: dma_alloc_coherent failed: 6291456 [ 26.881744] rproc remoteproc0: Failed to process resources: -12 [ 26.902221] omap_hwmod: ipu: failed to hardreset [ 26.909545] omap_hwmod: ipu: _wait_target_disable failed [ 26.916748] rproc remoteproc0: rproc_boot() failed -12 The M3 firmware load fails because of this. I have been looking at the git logs to see if this is fixed in the later checkins, since this is a bit old kernel. For various non-technical reasons which I have no control of, we can't move to a newer kernel. But I could backport any fixes done in newer kernel. Also I am totally new to memory management in the kernel, so any help in debugging is highly appreciated. thanks -- Ramakrishnan -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by kanga.kvack.org (Postfix) with ESMTP id 1BD416B0031 for ; Wed, 12 Mar 2014 19:29:10 -0400 (EDT) Received: by mail-pb0-f41.google.com with SMTP id jt11so225550pbb.14 for ; Wed, 12 Mar 2014 16:29:09 -0700 (PDT) Received: from LGEAMRELO02.lge.com (lgeamrelo02.lge.com. [156.147.1.126]) by mx.google.com with ESMTP id wp10si316217pbc.107.2014.03.12.16.29.07 for ; Wed, 12 Mar 2014 16:29:08 -0700 (PDT) Date: Thu, 13 Mar 2014 08:29:24 +0900 From: Minchan Kim Subject: Re: cma: alloc_contig_range test_pages_isolated .. failed Message-ID: <20140312232924.GK17828@bbox> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Ramakrishnan Muthukrishnan Cc: linux-mm@kvack.org, Laura Abbott Hello, On Tue, Mar 11, 2014 at 07:32:34PM +0530, Ramakrishnan Muthukrishnan wrote: > Hello linux-mm hackers, > > We have a TI OMAP4 based system running 3.4 kernel. OMAP4 has got 2 M3 > processors which is used for some media tasks. > > During bootup, the M3 firmware is loaded and it used CMA to allocate 3 > regions for DMA, as seen by these logs: > > [ 0.000000] cma: dma_declare_contiguous(size a400000, base > 99000000, limit 00000000) > [ 0.000000] cma: CMA: reserved 168 MiB at 99000000 > [ 0.000000] cma: dma_declare_contiguous(size 2000000, base > 00000000, limit 00000000) > [ 0.000000] cma: CMA: reserved 32 MiB at ad800000 > [ 0.000000] cma: dma_contiguous_reserve(limit af800000) > [ 0.000000] cma: dma_contiguous_reserve: reserving 16 MiB for global area > [ 0.000000] cma: dma_declare_contiguous(size 1000000, base > 00000000, limit af800000) > [ 0.000000] cma: CMA: reserved 16 MiB at ac000000 > [ 0.243652] cma: cma_init_reserved_areas() > [ 0.243682] cma: cma_create_area(base 00099000, count a800) > [ 0.253417] cma: cma_create_area: returned ed0ee400 > [...] > > We observed that if we reboot a system without unmounting the file > systems (like in abrupt power off..etc), after the fresh reboot, the > file system checks are performed, the firmware load is delayed by ~4 > seconds (compared to the one without fsck) and then we see the > following in the kernel bootup logs: > > [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) failed > [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) failed > [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) failed > [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) failed > [ 26.875213] rproc remoteproc0: dma_alloc_coherent failed: 6291456 > [ 26.881744] rproc remoteproc0: Failed to process resources: -12 > [ 26.902221] omap_hwmod: ipu: failed to hardreset > [ 26.909545] omap_hwmod: ipu: _wait_target_disable failed > [ 26.916748] rproc remoteproc0: rproc_boot() failed -12 > > The M3 firmware load fails because of this. I have been looking at the > git logs to see if this is fixed in the later checkins, since this is > a bit old kernel. For various non-technical reasons which I have no > control of, we can't move to a newer kernel. But I could backport any > fixes done in newer kernel. Also I am totally new to memory management > in the kernel, so any help in debugging is highly appreciated. Could you try this one? https://lkml.org/lkml/2012/8/31/313 I didn't reviewd that patch carefully but I guess you have similar problem. So, if it fixes your problem, we should review that patch carefully and merge if it doesn't have any problem and we couldn't find better solution. > > thanks > -- > Ramakrishnan > > -- > 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: email@kvack.org -- Kind regards, Minchan Kim -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by kanga.kvack.org (Postfix) with ESMTP id 972CB6B0031 for ; Wed, 12 Mar 2014 23:54:47 -0400 (EDT) Received: by mail-oa0-f53.google.com with SMTP id j17so468285oag.26 for ; Wed, 12 Mar 2014 20:54:47 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [2607:f8b0:4003:c02::232]) by mx.google.com with ESMTPS id kb7si682090oeb.141.2014.03.12.20.54.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Mar 2014 20:54:46 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i7so479237oag.23 for ; Wed, 12 Mar 2014 20:54:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140312232924.GK17828@bbox> References: <20140312232924.GK17828@bbox> From: Ramakrishnan Muthukrishnan Date: Thu, 13 Mar 2014 09:24:25 +0530 Message-ID: Subject: Re: cma: alloc_contig_range test_pages_isolated .. failed Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: linux-mm@kvack.org, Laura Abbott Hello, On Thu, Mar 13, 2014 at 4:59 AM, Minchan Kim wrote: > > On Tue, Mar 11, 2014 at 07:32:34PM +0530, Ramakrishnan Muthukrishnan wrote: >> Hello linux-mm hackers, >> >> We have a TI OMAP4 based system running 3.4 kernel. OMAP4 has got 2 M3 >> processors which is used for some media tasks. >> >> During bootup, the M3 firmware is loaded and it used CMA to allocate 3 >> regions for DMA, as seen by these logs: >> >> [ 0.000000] cma: dma_declare_contiguous(size a400000, base >> 99000000, limit 00000000) >> [ 0.000000] cma: CMA: reserved 168 MiB at 99000000 >> [ 0.000000] cma: dma_declare_contiguous(size 2000000, base >> 00000000, limit 00000000) >> [ 0.000000] cma: CMA: reserved 32 MiB at ad800000 >> [ 0.000000] cma: dma_contiguous_reserve(limit af800000) >> [ 0.000000] cma: dma_contiguous_reserve: reserving 16 MiB for global area >> [ 0.000000] cma: dma_declare_contiguous(size 1000000, base >> 00000000, limit af800000) >> [ 0.000000] cma: CMA: reserved 16 MiB at ac000000 >> [ 0.243652] cma: cma_init_reserved_areas() >> [ 0.243682] cma: cma_create_area(base 00099000, count a800) >> [ 0.253417] cma: cma_create_area: returned ed0ee400 >> [...] >> >> We observed that if we reboot a system without unmounting the file >> systems (like in abrupt power off..etc), after the fresh reboot, the >> file system checks are performed, the firmware load is delayed by ~4 >> seconds (compared to the one without fsck) and then we see the >> following in the kernel bootup logs: >> >> [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) failed >> [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) failed >> [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) failed >> [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) failed >> [ 26.875213] rproc remoteproc0: dma_alloc_coherent failed: 6291456 >> [ 26.881744] rproc remoteproc0: Failed to process resources: -12 >> [ 26.902221] omap_hwmod: ipu: failed to hardreset >> [ 26.909545] omap_hwmod: ipu: _wait_target_disable failed >> [ 26.916748] rproc remoteproc0: rproc_boot() failed -12 >> >> The M3 firmware load fails because of this. I have been looking at the >> git logs to see if this is fixed in the later checkins, since this is >> a bit old kernel. For various non-technical reasons which I have no >> control of, we can't move to a newer kernel. But I could backport any >> fixes done in newer kernel. Also I am totally new to memory management >> in the kernel, so any help in debugging is highly appreciated. > > Could you try this one? > https://lkml.org/lkml/2012/8/31/313 > I didn't reviewd that patch carefully but I guess you have similar problem. > So, if it fixes your problem, we should review that patch carefully and > merge if it doesn't have any problem and we couldn't find better solution. It didn't fix the problem, unfortunately. In fact my kernel already had that patch applied (by a TI engineer): commit df9cf0bdf4a59e0fe6604f92f52028c259da69ad Author: Guillaume Aubertin Date: Mon Sep 10 20:27:08 2012 +0800 CMA: removing buffers from LRU when migrating based on the fix provided by Laura Abbott : https://lkml.org/lkml/2012/8/31/313 Thanks Ramakrishnan -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by kanga.kvack.org (Postfix) with ESMTP id 5D2936B0031 for ; Thu, 13 Mar 2014 00:40:30 -0400 (EDT) Received: by mail-pa0-f50.google.com with SMTP id kq14so550087pab.9 for ; Wed, 12 Mar 2014 21:40:29 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com. [203.254.224.33]) by mx.google.com with ESMTPS id hh1si427458pac.382.2014.03.12.21.40.28 for (version=TLSv1 cipher=RC4-MD5 bits=128/128); Wed, 12 Mar 2014 21:40:29 -0700 (PDT) Received: from epcpsbgr5.samsung.com (u145.gpu120.samsung.co.kr [203.254.230.145]) by mailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N2C0039SYBDODE0@mailout3.samsung.com> for linux-mm@kvack.org; Thu, 13 Mar 2014 13:40:25 +0900 (KST) Message-id: <532136C1.5020502@samsung.com> Date: Thu, 13 Mar 2014 13:40:33 +0900 From: Heesub Shin MIME-version: 1.0 Subject: Re: cma: alloc_contig_range test_pages_isolated .. failed References: In-reply-to: Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ramakrishnan Muthukrishnan , linux-mm@kvack.org Hello, On 03/11/2014 11:02 PM, Ramakrishnan Muthukrishnan wrote: > [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) failed > [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) failed > [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) failed > [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) failed "memory-hotplug: fix pages missed by race rather than failing" by Minchan Kim (435b405) would also help you, which was merged after v3.4. -- Regards, heesub -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by kanga.kvack.org (Postfix) with ESMTP id D5DA56B0035 for ; Thu, 13 Mar 2014 09:43:45 -0400 (EDT) Received: by mail-ob0-f176.google.com with SMTP id wp18so1029187obc.35 for ; Thu, 13 Mar 2014 06:43:45 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [2607:f8b0:4003:c02::230]) by mx.google.com with ESMTPS id dq4si2490062oeb.34.2014.03.13.06.43.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 06:43:45 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id m1so1039475oag.21 for ; Thu, 13 Mar 2014 06:43:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <532136C1.5020502@samsung.com> References: <532136C1.5020502@samsung.com> From: Ramakrishnan Muthukrishnan Date: Thu, 13 Mar 2014 19:13:23 +0530 Message-ID: Subject: Re: cma: alloc_contig_range test_pages_isolated .. failed Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Heesub Shin Cc: linux-mm@kvack.org Hello On Thu, Mar 13, 2014 at 10:10 AM, Heesub Shin wrote: > > On 03/11/2014 11:02 PM, Ramakrishnan Muthukrishnan wrote: >> >> [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) failed >> [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) failed >> [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) failed >> [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) failed > > > "memory-hotplug: fix pages missed by race rather than failing" by Minchan > Kim (435b405) would also help you, which was merged after v3.4. Yes, I tried that and the associated parent patches as well but unfortunately that too didn't help. -- Ramakrishnan -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) by kanga.kvack.org (Postfix) with ESMTP id 025086B0037 for ; Thu, 13 Mar 2014 20:16:51 -0400 (EDT) Received: by mail-ig0-f180.google.com with SMTP id hl1so3848050igb.1 for ; Thu, 13 Mar 2014 17:16:51 -0700 (PDT) Received: from LGEMRELSE1Q.lge.com (LGEMRELSE1Q.lge.com. [156.147.1.111]) by mx.google.com with ESMTP id q6si3861243igr.23.2014.03.13.17.16.50 for ; Thu, 13 Mar 2014 17:16:51 -0700 (PDT) Date: Fri, 14 Mar 2014 09:16:58 +0900 From: Minchan Kim Subject: Re: cma: alloc_contig_range test_pages_isolated .. failed Message-ID: <20140314001658.GG16062@bbox> References: <20140312232924.GK17828@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Ramakrishnan Muthukrishnan Cc: linux-mm@kvack.org, Laura Abbott On Thu, Mar 13, 2014 at 09:24:25AM +0530, Ramakrishnan Muthukrishnan wrote: > Hello, > > On Thu, Mar 13, 2014 at 4:59 AM, Minchan Kim wrote: > > > > On Tue, Mar 11, 2014 at 07:32:34PM +0530, Ramakrishnan Muthukrishnan wrote: > >> Hello linux-mm hackers, > >> > >> We have a TI OMAP4 based system running 3.4 kernel. OMAP4 has got 2 M3 > >> processors which is used for some media tasks. > >> > >> During bootup, the M3 firmware is loaded and it used CMA to allocate 3 > >> regions for DMA, as seen by these logs: > >> > >> [ 0.000000] cma: dma_declare_contiguous(size a400000, base > >> 99000000, limit 00000000) > >> [ 0.000000] cma: CMA: reserved 168 MiB at 99000000 > >> [ 0.000000] cma: dma_declare_contiguous(size 2000000, base > >> 00000000, limit 00000000) > >> [ 0.000000] cma: CMA: reserved 32 MiB at ad800000 > >> [ 0.000000] cma: dma_contiguous_reserve(limit af800000) > >> [ 0.000000] cma: dma_contiguous_reserve: reserving 16 MiB for global area > >> [ 0.000000] cma: dma_declare_contiguous(size 1000000, base > >> 00000000, limit af800000) > >> [ 0.000000] cma: CMA: reserved 16 MiB at ac000000 > >> [ 0.243652] cma: cma_init_reserved_areas() > >> [ 0.243682] cma: cma_create_area(base 00099000, count a800) > >> [ 0.253417] cma: cma_create_area: returned ed0ee400 > >> [...] > >> > >> We observed that if we reboot a system without unmounting the file > >> systems (like in abrupt power off..etc), after the fresh reboot, the > >> file system checks are performed, the firmware load is delayed by ~4 > >> seconds (compared to the one without fsck) and then we see the > >> following in the kernel bootup logs: > >> > >> [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) failed > >> [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) failed > >> [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) failed > >> [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) failed > >> [ 26.875213] rproc remoteproc0: dma_alloc_coherent failed: 6291456 > >> [ 26.881744] rproc remoteproc0: Failed to process resources: -12 > >> [ 26.902221] omap_hwmod: ipu: failed to hardreset > >> [ 26.909545] omap_hwmod: ipu: _wait_target_disable failed > >> [ 26.916748] rproc remoteproc0: rproc_boot() failed -12 > >> > >> The M3 firmware load fails because of this. I have been looking at the > >> git logs to see if this is fixed in the later checkins, since this is > >> a bit old kernel. For various non-technical reasons which I have no > >> control of, we can't move to a newer kernel. But I could backport any > >> fixes done in newer kernel. Also I am totally new to memory management > >> in the kernel, so any help in debugging is highly appreciated. > > > > Could you try this one? > > https://lkml.org/lkml/2012/8/31/313 > > I didn't reviewd that patch carefully but I guess you have similar problem. > > So, if it fixes your problem, we should review that patch carefully and > > merge if it doesn't have any problem and we couldn't find better solution. > > It didn't fix the problem, unfortunately. In fact my kernel already > had that patch applied (by a TI engineer): > > commit df9cf0bdf4a59e0fe6604f92f52028c259da69ad > Author: Guillaume Aubertin > Date: Mon Sep 10 20:27:08 2012 +0800 > > CMA: removing buffers from LRU when migrating > > based on the fix provided by Laura Abbott : > https://lkml.org/lkml/2012/8/31/313 3.4 was initial version for CMA and AFAIR, there were lots of problem and have fixed until now. I don't know how many patches TI backported to 3.4 so it's really hard to see your problem. Anyway, patches I can suggest to you are following as [1] bb13ffeb9, mm: compaction: cache if a pageblock was scanned and no pages were isolated [2] 627260595, mm: compaction: fix bit ranges in {get,clear,set}_pageblock_skip() Totally, I forgot what they are but at least, Thierry had similar problem and it was fixed by that. https://lkml.org/lkml/2012/9/27/281 Hopefully, It helps you, too. And please keep in mind. In 3.4, CMA has many problems so although we might fix poped up problem, you could encounter others in runtime, too unless TI enginner follows recent fixes. > > Thanks > Ramakrishnan > > -- > 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: email@kvack.org -- Kind regards, Minchan Kim -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by kanga.kvack.org (Postfix) with ESMTP id 548386B0035 for ; Thu, 13 Mar 2014 20:41:27 -0400 (EDT) Received: by mail-pd0-f173.google.com with SMTP id z10so1793097pdj.18 for ; Thu, 13 Mar 2014 17:41:27 -0700 (PDT) Received: from lgeamrelo04.lge.com (lgeamrelo04.lge.com. [156.147.1.127]) by mx.google.com with ESMTP id nc6si3858207pbc.23.2014.03.13.17.41.23 for ; Thu, 13 Mar 2014 17:41:25 -0700 (PDT) Date: Fri, 14 Mar 2014 09:41:19 +0900 From: Joonsoo Kim Subject: Re: cma: alloc_contig_range test_pages_isolated .. failed Message-ID: <20140314004118.GA4150@lge.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Ramakrishnan Muthukrishnan Cc: linux-mm@kvack.org On Tue, Mar 11, 2014 at 07:32:34PM +0530, Ramakrishnan Muthukrishnan wrote: > Hello linux-mm hackers, > > We have a TI OMAP4 based system running 3.4 kernel. OMAP4 has got 2 M3 > processors which is used for some media tasks. > > During bootup, the M3 firmware is loaded and it used CMA to allocate 3 > regions for DMA, as seen by these logs: > > [ 0.000000] cma: dma_declare_contiguous(size a400000, base > 99000000, limit 00000000) > [ 0.000000] cma: CMA: reserved 168 MiB at 99000000 > [ 0.000000] cma: dma_declare_contiguous(size 2000000, base > 00000000, limit 00000000) > [ 0.000000] cma: CMA: reserved 32 MiB at ad800000 > [ 0.000000] cma: dma_contiguous_reserve(limit af800000) > [ 0.000000] cma: dma_contiguous_reserve: reserving 16 MiB for global area > [ 0.000000] cma: dma_declare_contiguous(size 1000000, base > 00000000, limit af800000) > [ 0.000000] cma: CMA: reserved 16 MiB at ac000000 > [ 0.243652] cma: cma_init_reserved_areas() > [ 0.243682] cma: cma_create_area(base 00099000, count a800) > [ 0.253417] cma: cma_create_area: returned ed0ee400 > [...] > > We observed that if we reboot a system without unmounting the file > systems (like in abrupt power off..etc), after the fresh reboot, the > file system checks are performed, the firmware load is delayed by ~4 > seconds (compared to the one without fsck) and then we see the > following in the kernel bootup logs: > > [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) failed > [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) failed > [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) failed > [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) failed > [ 26.875213] rproc remoteproc0: dma_alloc_coherent failed: 6291456 > [ 26.881744] rproc remoteproc0: Failed to process resources: -12 > [ 26.902221] omap_hwmod: ipu: failed to hardreset > [ 26.909545] omap_hwmod: ipu: _wait_target_disable failed > [ 26.916748] rproc remoteproc0: rproc_boot() failed -12 > > The M3 firmware load fails because of this. I have been looking at the > git logs to see if this is fixed in the later checkins, since this is > a bit old kernel. For various non-technical reasons which I have no > control of, we can't move to a newer kernel. But I could backport any > fixes done in newer kernel. Also I am totally new to memory management > in the kernel, so any help in debugging is highly appreciated. Hello, Is this log all? In the above log, test_pages_isolated() failed for a short time. Is it root cause of delayed firmware loading? Why "cma: dma_alloc_from_contiguous(): memory range at %p is busy, retrying" isn't appeared? There is possible race in start_isolate_page_range() and so on, so some pages in CMA region don't be moved to MIGRATE_ISOLATE list and test_pages_isolated() could fail. But, it doesn't last for a long time as far as I know. Thanks. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by kanga.kvack.org (Postfix) with ESMTP id E62F16B0035 for ; Thu, 13 Mar 2014 21:37:41 -0400 (EDT) Received: by mail-pb0-f41.google.com with SMTP id jt11so1913638pbb.28 for ; Thu, 13 Mar 2014 18:37:41 -0700 (PDT) Received: from smtp.codeaurora.org (smtp.codeaurora.org. [198.145.11.231]) by mx.google.com with ESMTPS id yj1si2564240pac.320.2014.03.13.18.37.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Mar 2014 18:37:39 -0700 (PDT) Message-ID: <53225D61.8090101@codeaurora.org> Date: Thu, 13 Mar 2014 18:37:37 -0700 From: Laura Abbott MIME-Version: 1.0 Subject: Re: cma: alloc_contig_range test_pages_isolated .. failed References: <20140312232924.GK17828@bbox> <20140314001658.GG16062@bbox> In-Reply-To: <20140314001658.GG16062@bbox> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim , Ramakrishnan Muthukrishnan Cc: linux-mm@kvack.org On 3/13/2014 5:16 PM, Minchan Kim wrote: > On Thu, Mar 13, 2014 at 09:24:25AM +0530, Ramakrishnan Muthukrishnan wrote: >> Hello, >> >> On Thu, Mar 13, 2014 at 4:59 AM, Minchan Kim wrote: >>> >>> On Tue, Mar 11, 2014 at 07:32:34PM +0530, Ramakrishnan Muthukrishnan wrote: >>>> Hello linux-mm hackers, >>>> >>>> We have a TI OMAP4 based system running 3.4 kernel. OMAP4 has got 2 M3 >>>> processors which is used for some media tasks. >>>> >>>> During bootup, the M3 firmware is loaded and it used CMA to allocate 3 >>>> regions for DMA, as seen by these logs: >>>> >>>> [ 0.000000] cma: dma_declare_contiguous(size a400000, base >>>> 99000000, limit 00000000) >>>> [ 0.000000] cma: CMA: reserved 168 MiB at 99000000 >>>> [ 0.000000] cma: dma_declare_contiguous(size 2000000, base >>>> 00000000, limit 00000000) >>>> [ 0.000000] cma: CMA: reserved 32 MiB at ad800000 >>>> [ 0.000000] cma: dma_contiguous_reserve(limit af800000) >>>> [ 0.000000] cma: dma_contiguous_reserve: reserving 16 MiB for global area >>>> [ 0.000000] cma: dma_declare_contiguous(size 1000000, base >>>> 00000000, limit af800000) >>>> [ 0.000000] cma: CMA: reserved 16 MiB at ac000000 >>>> [ 0.243652] cma: cma_init_reserved_areas() >>>> [ 0.243682] cma: cma_create_area(base 00099000, count a800) >>>> [ 0.253417] cma: cma_create_area: returned ed0ee400 >>>> [...] >>>> >>>> We observed that if we reboot a system without unmounting the file >>>> systems (like in abrupt power off..etc), after the fresh reboot, the >>>> file system checks are performed, the firmware load is delayed by ~4 >>>> seconds (compared to the one without fsck) and then we see the >>>> following in the kernel bootup logs: >>>> >>>> [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) failed >>>> [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) failed >>>> [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) failed >>>> [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) failed >>>> [ 26.875213] rproc remoteproc0: dma_alloc_coherent failed: 6291456 >>>> [ 26.881744] rproc remoteproc0: Failed to process resources: -12 >>>> [ 26.902221] omap_hwmod: ipu: failed to hardreset >>>> [ 26.909545] omap_hwmod: ipu: _wait_target_disable failed >>>> [ 26.916748] rproc remoteproc0: rproc_boot() failed -12 >>>> >>>> The M3 firmware load fails because of this. I have been looking at the >>>> git logs to see if this is fixed in the later checkins, since this is >>>> a bit old kernel. For various non-technical reasons which I have no >>>> control of, we can't move to a newer kernel. But I could backport any >>>> fixes done in newer kernel. Also I am totally new to memory management >>>> in the kernel, so any help in debugging is highly appreciated. >>> >>> Could you try this one? >>> https://lkml.org/lkml/2012/8/31/313 >>> I didn't reviewd that patch carefully but I guess you have similar problem. >>> So, if it fixes your problem, we should review that patch carefully and >>> merge if it doesn't have any problem and we couldn't find better solution. >> >> It didn't fix the problem, unfortunately. In fact my kernel already >> had that patch applied (by a TI engineer): >> >> commit df9cf0bdf4a59e0fe6604f92f52028c259da69ad >> Author: Guillaume Aubertin >> Date: Mon Sep 10 20:27:08 2012 +0800 >> >> CMA: removing buffers from LRU when migrating >> >> based on the fix provided by Laura Abbott : >> https://lkml.org/lkml/2012/8/31/313 > > 3.4 was initial version for CMA and AFAIR, there were lots of problem and > have fixed until now. I don't know how many patches TI backported to 3.4 > so it's really hard to see your problem. > > Anyway, patches I can suggest to you are following as > > [1] bb13ffeb9, mm: compaction: cache if a pageblock was scanned and no pages were isolated > [2] 627260595, mm: compaction: fix bit ranges in {get,clear,set}_pageblock_skip() > > Totally, I forgot what they are but at least, Thierry had similar problem > and it was fixed by that. > https://lkml.org/lkml/2012/9/27/281 > > Hopefully, It helps you, too. > > And please keep in mind. In 3.4, CMA has many problems so although we might > fix poped up problem, you could encounter others in runtime, too unless TI > enginner follows recent fixes. > > Can you try picking up c060f943d0929f3e429c5d9522290584f6281d6e (mm: use aligned zone start for pfn_to_bitidx calculation) and 7c45512df987c5619db041b5c9b80d281e26d3db (mm: fix pageblock bitmap allocation) The first commit fixed a known failure mode that caused isolation failures frequently and the second commit fixed a bug in the 1st commit. From experience though if you are hitting a large number of isolation failures that generally means the system is under memory/file pressure and the CMA pages aren't even eligible to be isolated yet (!PageLRU in isolate_migratepages_range) You can also try this 'unique enhancement' (It sounds better than performance dropping hack) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 9b61b9b..31b36e8 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -63,10 +63,20 @@ enum { MIGRATE_TYPES }; +static inline int get_pageblock_migratetype(struct page *page) +{ + return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end); +} + #ifdef CONFIG_CMA +static inline bool is_cma_pageblock(struct page *) +{ + return get_pageblock_migratetype(page) == MIGRATE_CMA; +} # define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA) #else # define is_migrate_cma(migratetype) false +#define is_cma_pageblock(page) false #endif #define for_each_migratetype_order(order, type) \ @@ -75,11 +85,6 @@ enum { extern int page_group_by_mobility_disabled; -static inline int get_pageblock_migratetype(struct page *page) -{ - return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end); -} - struct free_area { struct list_head free_list[MIGRATE_TYPES]; unsigned long nr_free; diff --git a/mm/filemap.c b/mm/filemap.c index 7a13f6a..1fa8e58 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -788,12 +788,21 @@ struct page *find_or_create_page(struct address_space *mapping, { struct page *page; int err; + gfp_t gfp_notmask = 0; + repeat: page = find_lock_page(mapping, index); if (!page) { - page = __page_cache_alloc(gfp_mask); +retry: + page = __page_cache_alloc(gfp_mask & ~gfp_notmask); if (!page) return NULL; + + if (is_cma_pageblock(page)) { + __free_page(page); + gfp_notmask |= __GFP_MOVABLE; + goto retry; + } /* * We want a regular kernel memory (not highmem or DMA etc) * allocation for the radix tree nodes, but we need to honour >> >> Thanks >> Ramakrishnan >> >> -- >> 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: email@kvack.org > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by kanga.kvack.org (Postfix) with ESMTP id BBEE56B005C for ; Fri, 14 Mar 2014 03:29:03 -0400 (EDT) Received: by mail-oa0-f48.google.com with SMTP id m1so2214834oag.35 for ; Fri, 14 Mar 2014 00:29:03 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [2607:f8b0:4003:c01::22f]) by mx.google.com with ESMTPS id ti9si1024451obc.28.2014.03.14.00.21.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 00:22:02 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id uy5so2168685obc.34 for ; Fri, 14 Mar 2014 00:21:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <53225D61.8090101@codeaurora.org> References: <20140312232924.GK17828@bbox> <20140314001658.GG16062@bbox> <53225D61.8090101@codeaurora.org> From: Ramakrishnan Muthukrishnan Date: Fri, 14 Mar 2014 12:51:12 +0530 Message-ID: Subject: Re: cma: alloc_contig_range test_pages_isolated .. failed Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: Minchan Kim , linux-mm@kvack.org On Fri, Mar 14, 2014 at 7:07 AM, Laura Abbott wrote: > On 3/13/2014 5:16 PM, Minchan Kim wrote: >> >> On Thu, Mar 13, 2014 at 09:24:25AM +0530, Ramakrishnan Muthukrishnan >> wrote: >>> >>> Hello, >>> >>> On Thu, Mar 13, 2014 at 4:59 AM, Minchan Kim wrote: >>>> >>>> >>>> On Tue, Mar 11, 2014 at 07:32:34PM +0530, Ramakrishnan Muthukrishnan >>>> wrote: >>>>> >>>>> Hello linux-mm hackers, >>>>> >>>>> We have a TI OMAP4 based system running 3.4 kernel. OMAP4 has got 2 M3 >>>>> processors which is used for some media tasks. >>>>> >>>>> During bootup, the M3 firmware is loaded and it used CMA to allocate 3 >>>>> regions for DMA, as seen by these logs: >>>>> >>>>> [ 0.000000] cma: dma_declare_contiguous(size a400000, base >>>>> 99000000, limit 00000000) >>>>> [ 0.000000] cma: CMA: reserved 168 MiB at 99000000 >>>>> [ 0.000000] cma: dma_declare_contiguous(size 2000000, base >>>>> 00000000, limit 00000000) >>>>> [ 0.000000] cma: CMA: reserved 32 MiB at ad800000 >>>>> [ 0.000000] cma: dma_contiguous_reserve(limit af800000) >>>>> [ 0.000000] cma: dma_contiguous_reserve: reserving 16 MiB for global >>>>> area >>>>> [ 0.000000] cma: dma_declare_contiguous(size 1000000, base >>>>> 00000000, limit af800000) >>>>> [ 0.000000] cma: CMA: reserved 16 MiB at ac000000 >>>>> [ 0.243652] cma: cma_init_reserved_areas() >>>>> [ 0.243682] cma: cma_create_area(base 00099000, count a800) >>>>> [ 0.253417] cma: cma_create_area: returned ed0ee400 >>>>> [...] >>>>> >>>>> We observed that if we reboot a system without unmounting the file >>>>> systems (like in abrupt power off..etc), after the fresh reboot, the >>>>> file system checks are performed, the firmware load is delayed by ~4 >>>>> seconds (compared to the one without fsck) and then we see the >>>>> following in the kernel bootup logs: >>>>> >>>>> [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) >>>>> failed >>>>> [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) >>>>> failed >>>>> [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) >>>>> failed >>>>> [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) >>>>> failed >>>>> [ 26.875213] rproc remoteproc0: dma_alloc_coherent failed: 6291456 >>>>> [ 26.881744] rproc remoteproc0: Failed to process resources: -12 >>>>> [ 26.902221] omap_hwmod: ipu: failed to hardreset >>>>> [ 26.909545] omap_hwmod: ipu: _wait_target_disable failed >>>>> [ 26.916748] rproc remoteproc0: rproc_boot() failed -12 >>>>> >>>>> The M3 firmware load fails because of this. I have been looking at the >>>>> git logs to see if this is fixed in the later checkins, since this is >>>>> a bit old kernel. For various non-technical reasons which I have no >>>>> control of, we can't move to a newer kernel. But I could backport any >>>>> fixes done in newer kernel. Also I am totally new to memory management >>>>> in the kernel, so any help in debugging is highly appreciated. >>>> >>>> >>>> Could you try this one? >>>> https://lkml.org/lkml/2012/8/31/313 >>>> I didn't reviewd that patch carefully but I guess you have similar >>>> problem. >>>> So, if it fixes your problem, we should review that patch carefully and >>>> merge if it doesn't have any problem and we couldn't find better >>>> solution. >>> >>> >>> It didn't fix the problem, unfortunately. In fact my kernel already >>> had that patch applied (by a TI engineer): >>> >>> commit df9cf0bdf4a59e0fe6604f92f52028c259da69ad >>> Author: Guillaume Aubertin >>> Date: Mon Sep 10 20:27:08 2012 +0800 >>> >>> CMA: removing buffers from LRU when migrating >>> >>> based on the fix provided by Laura Abbott : >>> https://lkml.org/lkml/2012/8/31/313 >> >> >> 3.4 was initial version for CMA and AFAIR, there were lots of problem and >> have fixed until now. I don't know how many patches TI backported to 3.4 >> so it's really hard to see your problem. >> >> Anyway, patches I can suggest to you are following as >> >> [1] bb13ffeb9, mm: compaction: cache if a pageblock was scanned and no >> pages were isolated >> [2] 627260595, mm: compaction: fix bit ranges in >> {get,clear,set}_pageblock_skip() >> >> Totally, I forgot what they are but at least, Thierry had similar problem >> and it was fixed by that. >> https://lkml.org/lkml/2012/9/27/281 >> >> Hopefully, It helps you, too. >> >> And please keep in mind. In 3.4, CMA has many problems so although we >> might >> fix poped up problem, you could encounter others in runtime, too unless TI >> enginner follows recent fixes. >> >> > > Can you try picking up c060f943d0929f3e429c5d9522290584f6281d6e > (mm: use aligned zone start for pfn_to_bitidx calculation) > and 7c45512df987c5619db041b5c9b80d281e26d3db > (mm: fix pageblock bitmap allocation) [...] > You can also try this 'unique enhancement' (It sounds better than > performance dropping hack) I initially tried only the above two commits, that didn't change anything as far as this behaviour is concerned. I then tried the "unique enhancement" patch, I still get the errors but not as frequently. I am yet to try the two patches suggested by Minchan Kim. [1] bb13ffeb9, mm: compaction: cache if a pageblock was scanned and no pages were isolated [2] 627260595, mm: compaction: fix bit ranges in {get,clear,set}_pageblock_skip() I will try them and report back. Thanks for the help. Ramakrishnan -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by kanga.kvack.org (Postfix) with ESMTP id 060146B0070 for ; Fri, 14 Mar 2014 04:20:06 -0400 (EDT) Received: by mail-pb0-f44.google.com with SMTP id rp16so2293799pbb.31 for ; Fri, 14 Mar 2014 01:20:06 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com. [119.145.14.64]) by mx.google.com with ESMTPS id wp10si4878347pbc.47.2014.03.14.01.20.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 14 Mar 2014 01:20:06 -0700 (PDT) Message-ID: <5322BB89.70208@huawei.com> Date: Fri, 14 Mar 2014 16:19:21 +0800 From: Jianguo Wu MIME-Version: 1.0 Subject: Re: cma: alloc_contig_range test_pages_isolated .. failed References: In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ramakrishnan Muthukrishnan Cc: linux-mm@kvack.org, Minchan Kim Hello, On 2014/3/11 22:02, Ramakrishnan Muthukrishnan wrote: > Hello linux-mm hackers, > > We have a TI OMAP4 based system running 3.4 kernel. OMAP4 has got 2 M3 > processors which is used for some media tasks. > > During bootup, the M3 firmware is loaded and it used CMA to allocate 3 > regions for DMA, as seen by these logs: > > [ 0.000000] cma: dma_declare_contiguous(size a400000, base > 99000000, limit 00000000) > [ 0.000000] cma: CMA: reserved 168 MiB at 99000000 > [ 0.000000] cma: dma_declare_contiguous(size 2000000, base > 00000000, limit 00000000) > [ 0.000000] cma: CMA: reserved 32 MiB at ad800000 > [ 0.000000] cma: dma_contiguous_reserve(limit af800000) > [ 0.000000] cma: dma_contiguous_reserve: reserving 16 MiB for global area > [ 0.000000] cma: dma_declare_contiguous(size 1000000, base > 00000000, limit af800000) > [ 0.000000] cma: CMA: reserved 16 MiB at ac000000 > [ 0.243652] cma: cma_init_reserved_areas() > [ 0.243682] cma: cma_create_area(base 00099000, count a800) > [ 0.253417] cma: cma_create_area: returned ed0ee400 > [...] > > We observed that if we reboot a system without unmounting the file > systems (like in abrupt power off..etc), after the fresh reboot, the > file system checks are performed, the firmware load is delayed by ~4 > seconds (compared to the one without fsck) and then we see the > following in the kernel bootup logs: > > [ 26.846313] alloc_contig_range test_pages_isolated(a2e00, a3400) failed > [ 26.853515] alloc_contig_range test_pages_isolated(a2e00, a3500) failed > [ 26.860809] alloc_contig_range test_pages_isolated(a3100, a3700) failed > [ 26.868133] alloc_contig_range test_pages_isolated(a3200, a3800) failed > [ 26.875213] rproc remoteproc0: dma_alloc_coherent failed: 6291456 > [ 26.881744] rproc remoteproc0: Failed to process resources: -12 > [ 26.902221] omap_hwmod: ipu: failed to hardreset > [ 26.909545] omap_hwmod: ipu: _wait_target_disable failed > [ 26.916748] rproc remoteproc0: rproc_boot() failed -12 > > The M3 firmware load fails because of this. I have been looking at the > git logs to see if this is fixed in the later checkins, since this is > a bit old kernel. For various non-technical reasons which I have no > control of, we can't move to a newer kernel. But I could backport any > fixes done in newer kernel. Also I am totally new to memory management > in the kernel, so any help in debugging is highly appreciated. > > thanks There is a possible that pages drain from pcp will be add to movable list, and get allocated again before test isolated. free_pcppages_bulk() { //mt can still be MIGRATE_MOVABLE even the pageblock's migratetype is MIGRATE_ISOLATE. mt = get_freepage_migratetype(page); /* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */ __free_one_page(page, zone, 0, mt); } we should use mt = get_pageblock_migratetype(page), but Minchan think it's not a good idea to call get_pageblock_migratetype in hotpath. http://marc.info/?l=linux-kernel&m=134555114706070&w=2 Thanks. -- 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: email@kvack.org