From: Wen Congyang <wency@cn.fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
rientjes@google.com, liuj97@gmail.com, len.brown@intel.com,
benh@kernel.crashing.org, paulus@samba.org,
minchan.kim@gmail.com, akpm@linux-foundation.org,
isimatu.yasuaki@jp.fujitsu.com, Christoph Lameter <cl@linux.com>
Subject: Re: [PATCH v3 8/9] memory-hotplug: fix NR_FREE_PAGES mismatch
Date: Fri, 19 Oct 2012 16:41:17 +0800 [thread overview]
Message-ID: <5081122D.1030906@cn.fujitsu.com> (raw)
In-Reply-To: <CAHGf_=ohk--=AKesgm+3U2qsSvjaVFBXn9c1KDru40GEpbM7gA@mail.gmail.com>
At 10/19/2012 03:41 PM, KOSAKI Motohiro Wrote:
> On Fri, Oct 19, 2012 at 2:46 AM, <wency@cn.fujitsu.com> wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>>
>> NR_FREE_PAGES will be wrong after offlining pages. We add/dec NR_FREE_PAGES
>> like this now:
>> 1. mova all pages in buddy system to MIGRATE_ISOLATE, and dec NR_FREE_PAGES
>
> move?
Yes.
__offline_pages()
start_isolate_page_range()
set_migratetype_isolate()
move_freepages_block() // move all pages in buddy system to MIGRATE_ISOLATE
__mod_zone_freepage_state() // dec NR_FREE_PAGES
>
>> 2. don't add NR_FREE_PAGES when it is freed and the migratetype is MIGRATE_ISOLATE
>> 3. dec NR_FREE_PAGES when offlining isolated pages.
>> 4. add NR_FREE_PAGES when undoing isolate pages.
>>
>> When we come to step 3, all pages are in MIGRATE_ISOLATE list, and NR_FREE_PAGES
>> are right. When we come to step4, all pages are not in buddy system, so we don't
>> change NR_FREE_PAGES in this step, but we change NR_FREE_PAGES in step3. So
>> NR_FREE_PAGES is wrong after offlining pages. So there is no need to change
>> NR_FREE_PAGES in step3.
>
> Sorry, I don't understand this two paragraph. Can you please elaborate more?
OK.
If we don't online/offline memory, we add NR_FREE_PAGES when we free a page,
and dec it when allocate a page. If we put the page into pcp, we don't add
NR_FREE_PAGES. We will add it when the page is moved to buddy system from pcp.
When we offline a memory section, we should dec NR_FREE_PAGES(we will add it
when onlining memory section). The pages may be freed or inuse:
1. If the page is freed, and in buddy system. We move it to MIGRATE_ISOLATE,
and dec NR_FREE_PAGES
2. If the page is inuse, we will migrate them to other memory section and free
them. We don't dec NR_FREE_PAGES when it is freed because we have decreased
it when it is allocated. We just put them in MIGRATE_ISOLATE.
3. If the page is in pcp, we call drain_all_pages() to put them to MIGRATE_ISOLATE.
We have decreased NR_FREE_PAGES when we allocate a page and put it in pcp.
So we just put them in MIGRATE_ISOLATE.
Step1 deals with case1, and step2 deals with case2,3
So NR_FREE_PAGES is right after all pages are put into MIGRATE_ISOLATE list.
Now offline_isolated_pages() will be called after all pages are put in
MIGRATE_ISOLATE list. So we should not change NR_FREE_PAGES now, but
we dec NR_FREE_PAGES in offline_isolated_pages().
>
> and one more trivial question: why do we need to call
> undo_isolate_page_range() from
> __offline_pages()?
We need to restore the page's migrate type to MIGRATE_MOVABLE.
>
>
>>
>> This patch also fixs a problem in step2: if the migratetype is MIGRATE_ISOLATE,
>> we should not add NR_FRR_PAGES when we remove pages from pcppages.
>
> Why drain_all_pages doesn't work?
>
drain_all_pages() deals with case3, and it should not touch NR_FREE_PAGES if it
put a page to MIGRATE_ISOLATE list. But we touch NR_FREE_PAGES without checking
where the page is put.
Thanks
Wen Congyang
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <wency@cn.fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
rientjes@google.com, liuj97@gmail.com, len.brown@intel.com,
benh@kernel.crashing.org, paulus@samba.org,
minchan.kim@gmail.com, akpm@linux-foundation.org,
isimatu.yasuaki@jp.fujitsu.com, Christoph Lameter <cl@linux.com>
Subject: Re: [PATCH v3 8/9] memory-hotplug: fix NR_FREE_PAGES mismatch
Date: Fri, 19 Oct 2012 16:41:17 +0800 [thread overview]
Message-ID: <5081122D.1030906@cn.fujitsu.com> (raw)
In-Reply-To: <CAHGf_=ohk--=AKesgm+3U2qsSvjaVFBXn9c1KDru40GEpbM7gA@mail.gmail.com>
At 10/19/2012 03:41 PM, KOSAKI Motohiro Wrote:
> On Fri, Oct 19, 2012 at 2:46 AM, <wency@cn.fujitsu.com> wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>>
>> NR_FREE_PAGES will be wrong after offlining pages. We add/dec NR_FREE_PAGES
>> like this now:
>> 1. mova all pages in buddy system to MIGRATE_ISOLATE, and dec NR_FREE_PAGES
>
> move?
Yes.
__offline_pages()
start_isolate_page_range()
set_migratetype_isolate()
move_freepages_block() // move all pages in buddy system to MIGRATE_ISOLATE
__mod_zone_freepage_state() // dec NR_FREE_PAGES
>
>> 2. don't add NR_FREE_PAGES when it is freed and the migratetype is MIGRATE_ISOLATE
>> 3. dec NR_FREE_PAGES when offlining isolated pages.
>> 4. add NR_FREE_PAGES when undoing isolate pages.
>>
>> When we come to step 3, all pages are in MIGRATE_ISOLATE list, and NR_FREE_PAGES
>> are right. When we come to step4, all pages are not in buddy system, so we don't
>> change NR_FREE_PAGES in this step, but we change NR_FREE_PAGES in step3. So
>> NR_FREE_PAGES is wrong after offlining pages. So there is no need to change
>> NR_FREE_PAGES in step3.
>
> Sorry, I don't understand this two paragraph. Can you please elaborate more?
OK.
If we don't online/offline memory, we add NR_FREE_PAGES when we free a page,
and dec it when allocate a page. If we put the page into pcp, we don't add
NR_FREE_PAGES. We will add it when the page is moved to buddy system from pcp.
When we offline a memory section, we should dec NR_FREE_PAGES(we will add it
when onlining memory section). The pages may be freed or inuse:
1. If the page is freed, and in buddy system. We move it to MIGRATE_ISOLATE,
and dec NR_FREE_PAGES
2. If the page is inuse, we will migrate them to other memory section and free
them. We don't dec NR_FREE_PAGES when it is freed because we have decreased
it when it is allocated. We just put them in MIGRATE_ISOLATE.
3. If the page is in pcp, we call drain_all_pages() to put them to MIGRATE_ISOLATE.
We have decreased NR_FREE_PAGES when we allocate a page and put it in pcp.
So we just put them in MIGRATE_ISOLATE.
Step1 deals with case1, and step2 deals with case2,3
So NR_FREE_PAGES is right after all pages are put into MIGRATE_ISOLATE list.
Now offline_isolated_pages() will be called after all pages are put in
MIGRATE_ISOLATE list. So we should not change NR_FREE_PAGES now, but
we dec NR_FREE_PAGES in offline_isolated_pages().
>
> and one more trivial question: why do we need to call
> undo_isolate_page_range() from
> __offline_pages()?
We need to restore the page's migrate type to MIGRATE_MOVABLE.
>
>
>>
>> This patch also fixs a problem in step2: if the migratetype is MIGRATE_ISOLATE,
>> we should not add NR_FRR_PAGES when we remove pages from pcppages.
>
> Why drain_all_pages doesn't work?
>
drain_all_pages() deals with case3, and it should not touch NR_FREE_PAGES if it
put a page to MIGRATE_ISOLATE list. But we touch NR_FREE_PAGES without checking
where the page is put.
Thanks
Wen Congyang
next prev parent reply other threads:[~2012-10-19 8:35 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 6:46 [PATCH v3 0/9] bugfix for memory hotplug wency
2012-10-19 6:46 ` wency
2012-10-19 6:46 ` [PATCH v3 1/9] suppress "Device memoryX does not have a release() function" warning wency
2012-10-19 6:46 ` wency
2012-10-19 6:46 ` [PATCH v3 2/9] suppress "Device nodeX " wency
2012-10-19 6:46 ` wency
2012-10-19 6:53 ` KOSAKI Motohiro
2012-10-19 6:53 ` KOSAKI Motohiro
2012-10-22 22:52 ` Andrew Morton
2012-10-22 22:52 ` Andrew Morton
2012-10-22 23:00 ` Greg KH
2012-10-22 23:00 ` Greg KH
2012-10-19 6:46 ` [PATCH v3 3/9] memory-hotplug: flush the work for the node when the node is offlined wency
2012-10-19 6:46 ` wency
2012-10-19 7:01 ` KOSAKI Motohiro
2012-10-19 7:01 ` KOSAKI Motohiro
2012-10-19 7:28 ` Wen Congyang
2012-10-19 7:28 ` Wen Congyang
2012-10-19 6:46 ` [PATCH v3 4/9] clear the memory to store struct page wency
2012-10-19 6:46 ` wency
2012-10-19 7:02 ` KOSAKI Motohiro
2012-10-19 7:02 ` KOSAKI Motohiro
2012-10-26 9:44 ` Wen Congyang
2012-10-26 9:44 ` Wen Congyang
2012-10-29 21:10 ` Andrew Morton
2012-10-29 21:10 ` Andrew Morton
2012-10-30 2:18 ` Wen Congyang
2012-10-30 2:18 ` Wen Congyang
2012-10-30 2:41 ` Andrew Morton
2012-10-30 2:41 ` Andrew Morton
2012-10-30 2:48 ` Wen Congyang
2012-10-30 2:48 ` Wen Congyang
2012-10-19 6:46 ` [PATCH v3 5/9] memory-hotplug: skip HWPoisoned page when offlining pages wency
2012-10-19 6:46 ` wency
2012-10-19 6:46 ` [PATCH v3 6/9] memory-hotplug: update mce_bad_pages when removing the memory wency
2012-10-19 6:46 ` wency
2012-10-19 7:06 ` KOSAKI Motohiro
2012-10-19 7:06 ` KOSAKI Motohiro
2012-10-19 7:18 ` Wen Congyang
2012-10-19 7:18 ` Wen Congyang
2012-10-19 6:46 ` [PATCH v3 7/9] memory-hotplug: auto offline page_cgroup when onlining memory block failed wency
2012-10-19 6:46 ` wency
2012-10-19 6:46 ` [PATCH v3 8/9] memory-hotplug: fix NR_FREE_PAGES mismatch wency
2012-10-19 6:46 ` wency
2012-10-19 7:41 ` KOSAKI Motohiro
2012-10-19 7:41 ` KOSAKI Motohiro
2012-10-19 8:41 ` Wen Congyang [this message]
2012-10-19 8:41 ` Wen Congyang
2012-10-19 6:46 ` [PATCH v3 9/9] memory-hotplug: allocate zone's pcp before onlining pages wency
2012-10-19 6:46 ` wency
2012-10-19 7:07 ` KOSAKI Motohiro
2012-10-19 7:07 ` KOSAKI Motohiro
2012-10-19 8:06 ` [PATCH v3 0/9] bugfix for memory hotplug Yasuaki Ishimatsu
2012-10-19 8:06 ` Yasuaki Ishimatsu
2012-10-19 8:19 ` Yasuaki Ishimatsu
2012-10-19 8:19 ` Yasuaki Ishimatsu
2012-10-19 8:45 ` Wen Congyang
2012-10-19 8:45 ` Wen Congyang
2012-10-19 9:39 ` Yasuaki Ishimatsu
2012-10-19 9:39 ` Yasuaki Ishimatsu
2012-10-19 10:15 ` Wen Congyang
2012-10-19 10:15 ` Wen Congyang
2012-10-22 22:38 ` Andrew Morton
2012-10-22 22:38 ` Andrew Morton
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=5081122D.1030906@cn.fujitsu.com \
--to=wency@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=cl@linux.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuj97@gmail.com \
--cc=minchan.kim@gmail.com \
--cc=paulus@samba.org \
--cc=rientjes@google.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 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.