From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Hanjun Guo <guohanjun@huawei.com>,
"Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
Laura Abbott <labbott@redhat.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Sasha Levin <sasha.levin@oracle.com>,
Laura Abbott <lauraa@codeaurora.org>,
qiuxishi <qiuxishi@huawei.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>,
dingtinahong <dingtianhong@huawei.com>,
chenjie6@huawei.com, "linux-mm@kvack.org" <linux-mm@kvack.org>,
Lucas Stach <l.stach@pengutronix.de>
Subject: Re: Suspicious error for CMA stress test
Date: Wed, 23 Mar 2016 13:44:07 +0900 [thread overview]
Message-ID: <20160323044407.GB4624@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <56EC0C41.70503@suse.cz>
On Fri, Mar 18, 2016 at 03:10:09PM +0100, Vlastimil Babka wrote:
> On 03/17/2016 04:52 PM, Joonsoo Kim wrote:
> > 2016-03-18 0:43 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>:
> >>>>>>
> >>>>>> Okay. I used following slightly optimized version and I need to
> >>>>>> add 'max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1)'
> >>>>>> to yours. Please consider it, too.
> >>>>>
> >>>>> Hmm, this one is not work, I still can see the bug is there after
> >>>>> applying
> >>>>> this patch, did I miss something?
> >>>>
> >>>> I may find that there is a bug which was introduced by me some time
> >>>> ago. Could you test following change in __free_one_page() on top of
> >>>> Vlastimil's patch?
> >>>>
> >>>> -page_idx = pfn & ((1 << max_order) - 1);
> >>>> +page_idx = pfn & ((1 << MAX_ORDER) - 1);
> >>>
> >>>
> >>> I tested Vlastimil's patch + your change with stress for more than half
> >>> hour, the bug
> >>> I reported is gone :)
> >>
> >>
> >> Oh, ok, will try to send proper patch, once I figure out what to write in
> >> the changelog :)
> >
> > Thanks in advance!
> >
>
> OK, here it is. Hanjun can you please retest this, as I'm not sure if you had
> the same code due to the followup one-liner patches in the thread. Lucas, see if
> it helps with your issue as well. Laura and Joonsoo, please also test and review
> and check changelog if my perception of the problem is accurate :)
>
> Thanks
>
> ----8<----
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Fri, 18 Mar 2016 14:22:31 +0100
> Subject: [PATCH] mm/page_alloc: prevent merging between isolated and other
> pageblocks
>
> Hanjun Guo has reported that a CMA stress test causes broken accounting of
> CMA and free pages:
>
> > Before the test, I got:
> > -bash-4.3# cat /proc/meminfo | grep Cma
> > CmaTotal: 204800 kB
> > CmaFree: 195044 kB
> >
> >
> > After running the test:
> > -bash-4.3# cat /proc/meminfo | grep Cma
> > CmaTotal: 204800 kB
> > CmaFree: 6602584 kB
> >
> > So the freed CMA memory is more than total..
> >
> > Also the the MemFree is more than mem total:
> >
> > -bash-4.3# cat /proc/meminfo
> > MemTotal: 16342016 kB
> > MemFree: 22367268 kB
> > MemAvailable: 22370528 kB
>
> Laura Abbott has confirmed the issue and suspected the freepage accounting
> rewrite around 3.18/4.0 by Joonsoo Kim. Joonsoo had a theory that this is
> caused by unexpected merging between MIGRATE_ISOLATE and MIGRATE_CMA
> pageblocks:
>
> > CMA isolates MAX_ORDER aligned blocks, but, during the process,
> > partialy isolated block exists. If MAX_ORDER is 11 and
> > pageblock_order is 9, two pageblocks make up MAX_ORDER
> > aligned block and I can think following scenario because pageblock
> > (un)isolation would be done one by one.
> >
> > (each character means one pageblock. 'C', 'I' means MIGRATE_CMA,
> > MIGRATE_ISOLATE, respectively.
> >
> > CC -> IC -> II (Isolation)
> > II -> CI -> CC (Un-isolation)
> >
> > If some pages are freed at this intermediate state such as IC or CI,
> > that page could be merged to the other page that is resident on
> > different type of pageblock and it will cause wrong freepage count.
>
> This was supposed to be prevented by CMA operating on MAX_ORDER blocks, but
> since it doesn't hold the zone->lock between pageblocks, a race window does
> exist.
>
> It's also likely that unexpected merging can occur between MIGRATE_ISOLATE
> and non-CMA pageblocks. This should be prevented in __free_one_page() since
> commit 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated
> pageblock"). However, we only check the migratetype of the pageblock where
> buddy merging has been initiated, not the migratetype of the buddy pageblock
> (or group of pageblocks) which can be MIGRATE_ISOLATE.
>
> Joonsoo has suggested checking for buddy migratetype as part of
> page_is_buddy(), but that would add extra checks in allocator hotpath and
> bloat-o-meter has shown significant code bloat (the function is inline).
>
> This patch reduces the bloat at some expense of more complicated code. The
> buddy-merging while-loop in __free_one_page() is initially bounded to
> pageblock_border and without any migratetype checks. The checks are placed
> outside, bumping the max_order if merging is allowed, and returning to the
> while-loop with a statement which can't be possibly considered harmful.
>
> This fixes the accounting bug and also removes the arguably weird state in the
> original commit 3c605096d315 where buddies could be left unmerged.
>
> Fixes: 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock")
> Link: https://lkml.org/lkml/2016/3/2/280
> Reported-by: Hanjun Guo <guohanjun@huawei.com>
> Debugged-by: Laura Abbott <labbott@redhat.com>
> Debugged-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Cc: <stable@vger.kernel.org> # 3.18+
> ---
> mm/page_alloc.c | 46 +++++++++++++++++++++++++++++++++-------------
> 1 file changed, 33 insertions(+), 13 deletions(-)
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Thanks for taking care of this issue!.
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-03-23 4:42 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <56D6F008.1050600@huawei.com>
2016-03-03 1:25 ` Laura Abbott
2016-03-03 6:07 ` Hanjun Guo
2016-03-03 7:42 ` Joonsoo Kim
2016-03-03 7:58 ` Hanjun Guo
2016-03-03 12:49 ` Hanjun Guo
2016-03-03 18:52 ` Laura Abbott
2016-03-04 2:09 ` Joonsoo Kim
2016-03-04 6:09 ` Hanjun Guo
2016-03-04 2:02 ` Joonsoo Kim
2016-03-04 4:32 ` Joonsoo Kim
2016-03-04 6:05 ` Hanjun Guo
2016-03-04 6:38 ` Joonsoo Kim
2016-03-04 7:35 ` Hanjun Guo
2016-03-07 4:34 ` Joonsoo Kim
2016-03-07 8:16 ` Leizhen (ThunderTown)
2016-03-07 18:42 ` Laura Abbott
2016-03-08 1:54 ` Leizhen (ThunderTown)
2016-03-09 1:23 ` Leizhen (ThunderTown)
2016-03-11 15:00 ` Joonsoo Kim
2016-03-11 17:07 ` Vlastimil Babka
2016-03-14 6:49 ` Joonsoo Kim
2016-03-14 7:06 ` Vlastimil Babka
2016-03-14 7:18 ` Joonsoo Kim
2016-03-14 12:30 ` Vlastimil Babka
2016-03-14 14:10 ` Joonsoo Kim
2016-03-16 12:03 ` Vlastimil Babka
2016-03-16 9:44 ` Hanjun Guo
2016-03-17 6:54 ` Joonsoo Kim
2016-03-17 9:24 ` Hanjun Guo
2016-03-17 15:31 ` Joonsoo Kim
2016-03-18 2:03 ` Hanjun Guo
2016-03-17 15:43 ` Vlastimil Babka
2016-03-17 15:52 ` Joonsoo Kim
2016-03-18 13:32 ` Lucas Stach
2016-03-21 4:42 ` Joonsoo Kim
2016-03-22 14:56 ` Lucas Stach
2016-03-23 4:42 ` Joonsoo Kim
2016-03-18 14:10 ` Vlastimil Babka
2016-03-18 14:42 ` Lucas Stach
2016-03-18 20:58 ` Vlastimil Babka
2016-03-22 14:47 ` Lucas Stach
2016-03-19 7:24 ` Hanjun Guo
2016-03-19 22:11 ` Vlastimil Babka
2016-03-23 4:44 ` Joonsoo Kim [this message]
2016-03-23 8:26 ` Vlastimil Babka
2016-03-23 8:32 ` Joonsoo Kim
2016-03-18 12:29 ` Vlastimil Babka
2016-03-08 4:03 ` Hanjun Guo
2016-03-07 12:59 ` Vlastimil Babka
2016-03-08 7:48 ` Joonsoo Kim
2016-03-08 10:45 ` Xishi Qiu
2016-03-08 15:36 ` Joonsoo Kim
2016-03-09 2:18 ` Xishi Qiu
2016-03-04 5:33 ` Hanjun Guo
2016-03-08 1:42 ` Xishi Qiu
2016-03-08 8:09 ` Joonsoo Kim
2016-03-04 6:59 ` Hanjun Guo
2016-03-07 4:40 ` Joonsoo Kim
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=20160323044407.GB4624@js1304-P5Q-DELUXE \
--to=iamjoonsoo.kim@lge.com \
--cc=Catalin.Marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=chenjie6@huawei.com \
--cc=dingtianhong@huawei.com \
--cc=guohanjun@huawei.com \
--cc=l.stach@pengutronix.de \
--cc=labbott@redhat.com \
--cc=lauraa@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=qiuxishi@huawei.com \
--cc=sasha.levin@oracle.com \
--cc=thunder.leizhen@huawei.com \
--cc=vbabka@suse.cz \
--cc=will.deacon@arm.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox