From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Rik van Riel <riel@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Mel Gorman <mgorman@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Minchan Kim <minchan@kernel.org>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
Zhang Yanfei <zhangyanfei@cn.fujitsu.com>,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Wen Congyang <wency@cn.fujitsu.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Michal Nazarewicz <mina86@mina86.com>,
Laura Abbott <lauraa@codeaurora.org>,
Heesub Shin <heesub.shin@samsung.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Ritesh Harjani <ritesh.list@gmail.com>,
t.stanislaws@samsung.com, Gioh Kim <gioh.kim@lge.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: [PATCH 00/10] fix freepage count problems due to memory isolation
Date: Fri, 4 Jul 2014 16:57:45 +0900 [thread overview]
Message-ID: <1404460675-24456-1-git-send-email-iamjoonsoo.kim@lge.com> (raw)
Hello,
This patchset aims at fixing problems due to memory isolation found by
testing my patchset [1].
These are really subtle problems so I can be wrong. If you find what I am
missing, please let me know.
Before describing bugs itself, I first explain definition of freepage.
1. pages on buddy list are counted as freepage.
2. pages on isolate migratetype buddy list are *not* counted as freepage.
3. pages on cma buddy list are counted as CMA freepage, too.
4. pages for guard are *not* counted as freepage.
Now, I describe problems and related patch.
1. Patch 2: If guard page are cleared and merged into isolate buddy list,
we should not add freepage count.
2. Patch 3: When the page return back from pcp to buddy, we should
account it to freepage counter. In this case, we should check the
pageblock migratetype of the page and should insert the page into
appropriate buddy list. Although we checked it in current code, we
didn't insert the page into appropriate buddy list so that freepage
counting can be wrong.
3. Patch 4: There is race condition so that some freepages could be
on isolate buddy list. If so, we can't use this page until next isolation
attempt on this pageblock.
4. Patch 5: There is race condition that page on isolate pageblock
can go into non-isolate buddy list. If so, buddy allocator would
merge pages on non-isolate buddy list and isolate buddy list, respectively,
and freepage count will be wrong.
5. Patch 9: move_freepages(_block) returns *not* number of moved pages.
Instead, it returns number of pages linked in that migratetype buddy list.
So accouting with this return value makes freepage count wrong.
6. Patch 10: buddy allocator would merge pages on non-isolate buddy list
and isolate buddy list, respectively. This leads to freepage counting
problem so fix it by stopping merging in this case.
Without patchset [1], above problem doesn't happens on my CMA allocation
test, because CMA reserved pages aren't used at all. So there is no
chance for above race.
With patchset [1], I did simple CMA allocation test and get below result.
- Virtual machine, 4 cpus, 1024 MB memory, 256 MB CMA reservation
- run kernel build (make -j16) on background
- 30 times CMA allocation(8MB * 30 = 240MB) attempts in 5 sec interval
- Result: more than 5000 freepage count are missed
With patchset [1] and this patchset, I found that no freepage count are
missed so that I conclude that problems are solved.
These problems can be possible on memory hot remove users, although
I didn't check it further.
Other patches are either for the base to fix these problems or for
simple clean-up. Please see individual patches for more information.
This patchset is based on linux-next-20140703.
Thanks.
[1]: Aggressively allocate the pages on cma reserved memory
https://lkml.org/lkml/2014/5/30/291
Joonsoo Kim (10):
mm/page_alloc: remove unlikely macro on free_one_page()
mm/page_alloc: correct to clear guard attribute in DEBUG_PAGEALLOC
mm/page_alloc: handle page on pcp correctly if it's pageblock is
isolated
mm/page_alloc: carefully free the page on isolate pageblock
mm/page_alloc: optimize and unify pageblock migratetype check in free
path
mm/page_alloc: separate freepage migratetype interface
mm/page_alloc: store migratetype of the buddy list into freepage
correctly
mm/page_alloc: use get_onbuddy_migratetype() to get buddy list type
mm/page_alloc: fix possible wrongly calculated freepage counter
mm/page_alloc: Stop merging pages on non-isolate and isolate buddy
list
include/linux/mm.h | 30 +++++++--
include/linux/mmzone.h | 5 ++
include/linux/page-isolation.h | 8 +++
mm/page_alloc.c | 138 +++++++++++++++++++++++++++++-----------
mm/page_isolation.c | 18 ++----
5 files changed, 147 insertions(+), 52 deletions(-)
--
1.7.9.5
--
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 reply other threads:[~2014-07-04 7:53 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-04 7:57 Joonsoo Kim [this message]
2014-07-04 7:57 ` [PATCH 01/10] mm/page_alloc: remove unlikely macro on free_one_page() Joonsoo Kim
2014-07-04 12:03 ` Vlastimil Babka
2014-07-07 4:58 ` Joonsoo Kim
2014-07-04 12:52 ` Michal Nazarewicz
2014-07-04 12:53 ` Michal Nazarewicz
2014-07-04 7:57 ` [PATCH 02/10] mm/page_alloc: correct to clear guard attribute in DEBUG_PAGEALLOC Joonsoo Kim
2014-07-07 14:50 ` Vlastimil Babka
2014-07-04 7:57 ` [PATCH 03/10] mm/page_alloc: handle page on pcp correctly if it's pageblock is isolated Joonsoo Kim
2014-07-07 8:25 ` Gioh Kim
2014-07-08 7:18 ` Vlastimil Babka
2014-07-07 15:19 ` Vlastimil Babka
2014-07-14 6:24 ` Joonsoo Kim
2014-07-04 7:57 ` [PATCH 04/10] mm/page_alloc: carefully free the page on isolate pageblock Joonsoo Kim
2014-07-07 15:43 ` Vlastimil Babka
2014-07-04 7:57 ` [PATCH 05/10] mm/page_alloc: optimize and unify pageblock migratetype check in free path Joonsoo Kim
2014-07-07 15:50 ` Vlastimil Babka
2014-07-14 6:28 ` Joonsoo Kim
2014-07-04 7:57 ` [PATCH 06/10] mm/page_alloc: separate freepage migratetype interface Joonsoo Kim
2014-07-04 7:57 ` [PATCH 07/10] mm/page_alloc: store migratetype of the buddy list into freepage correctly Joonsoo Kim
2014-07-04 7:57 ` [PATCH 08/10] mm/page_alloc: use get_onbuddy_migratetype() to get buddy list type Joonsoo Kim
2014-07-07 15:57 ` Vlastimil Babka
2014-07-08 1:01 ` Gioh Kim
2014-07-08 7:23 ` Vlastimil Babka
2014-07-14 6:34 ` Joonsoo Kim
2014-07-04 7:57 ` [PATCH 09/10] mm/page_alloc: fix possible wrongly calculated freepage counter Joonsoo Kim
2014-07-04 7:57 ` [PATCH 10/10] mm/page_alloc: Stop merging pages on non-isolate and isolate buddy list Joonsoo Kim
2014-07-04 15:33 ` [PATCH 00/10] fix freepage count problems due to memory isolation Vlastimil Babka
2014-07-07 4:49 ` Joonsoo Kim
2014-07-07 14:33 ` Vlastimil Babka
2014-07-14 6:22 ` Joonsoo Kim
2014-07-14 9:49 ` Vlastimil Babka
2014-07-15 8:28 ` Joonsoo Kim
2014-07-15 8:36 ` Vlastimil Babka
2014-07-15 9:39 ` Joonsoo Kim
2014-07-15 10:00 ` Peter Zijlstra
2014-07-16 8:44 ` Joonsoo Kim
2014-07-16 8:43 ` Joonsoo Kim
2014-07-16 11:14 ` Vlastimil Babka
2014-07-17 6:12 ` Joonsoo Kim
2014-07-17 9:14 ` Vlastimil Babka
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=1404460675-24456-1-git-send-email-iamjoonsoo.kim@lge.com \
--to=iamjoonsoo.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=b.zolnierkie@samsung.com \
--cc=gioh.kim@lge.com \
--cc=hannes@cmpxchg.org \
--cc=heesub.shin@samsung.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=lauraa@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mgorman@suse.de \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=ritesh.list@gmail.com \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=t.stanislaws@samsung.com \
--cc=tangchen@cn.fujitsu.com \
--cc=wency@cn.fujitsu.com \
--cc=zhangyanfei@cn.fujitsu.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