From: Wei Yang <richard.weiyang@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Wei Yang <richard.weiyang@gmail.com>,
Oscar Salvador <osalvador@suse.de>,
linux-mm@kvack.org, akpm@linux-foundation.org, david@redhat.com
Subject: Re: [PATCH v2] mm, page_isolation: remove drain_all_pages() in set_migratetype_isolate()
Date: Wed, 19 Dec 2018 14:33:27 +0000 [thread overview]
Message-ID: <20181219143327.wdsufbn2oh6ygnne@master> (raw)
In-Reply-To: <20181219141343.GN5758@dhcp22.suse.cz>
On Wed, Dec 19, 2018 at 03:13:43PM +0100, Michal Hocko wrote:
>On Wed 19-12-18 13:53:07, Wei Yang wrote:
>> On Wed, Dec 19, 2018 at 10:57:19AM +0100, Oscar Salvador wrote:
>> >On Wed, Dec 19, 2018 at 10:51:10AM +0100, Michal Hocko wrote:
>> >> On Wed 19-12-18 04:46:56, Wei Yang wrote:
>> >> > Below is a brief call flow for __offline_pages() and
>> >> > alloc_contig_range():
>> >> >
>> >> > __offline_pages()/alloc_contig_range()
>> >> > start_isolate_page_range()
>> >> > set_migratetype_isolate()
>> >> > drain_all_pages()
>> >> > drain_all_pages()
>> >> >
>> >> > Current logic is: isolate and drain pcp list for each pageblock and
>> >> > drain pcp list again. This is not necessary and we could just drain pcp
>> >> > list once after isolate this whole range.
>> >> >
>> >> > The reason is start_isolate_page_range() will set the migrate type of
>> >> > a range to MIGRATE_ISOLATE. After doing so, this range will never be
>> >> > allocated from Buddy, neither to a real user nor to pcp list.
>> >>
>> >> But it is important to note that those pages still can be allocated from
>> >> the pcp lists until we do drain_all_pages().
>> >
>> >I had the same fear, but then I saw that move_freepages_block()->move_freepages() moves
>> >the pages to a new list:
>> >
>> ><--
>> >list_move(&page->lru,
>> > &zone->free_area[order].free_list[migratetype]);
>> >-->
>> >
>> >
>> >But looking at it again, I see that this is only for BuddyPages, so I guess
>> >that pcp-pages do not really get unlinked, so we could still allocate them.
>>
>> Well, I think you are right. But with this in mind, current code looks
>> buggy.
>>
>> Between has_unmovable_pages() and drain_all_pages(), others still could
>> allocate pages on pcp list, right? This means we thought we have
>> isolated the range, but not.
>
>THere is no guarantee in that regards and I believe there is also no
>demand for such a strong semantic. Or I do not see it at least.
If there is no demand for this, allocating page before drain_all_pages()
is reasonable. The time gap between isolating page and drain_all_pages
is fine.
Then I am confused about the objection to this patch. Finally, we drain
all the pages in pcp list and the range is isolated.
>--
>Michal Hocko
>SUSE Labs
--
Wei Yang
Help you, Help me
next prev parent reply other threads:[~2018-12-19 14:33 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 2:39 [PATCH] " Wei Yang
2018-12-14 3:57 ` Andrew Morton
2018-12-14 7:01 ` Wei Yang
2018-12-14 15:17 ` Wei Yang
2018-12-17 12:21 ` Michal Hocko
2018-12-18 20:48 ` Wei Yang
2018-12-17 12:25 ` Michal Hocko
2018-12-17 15:08 ` Wei Yang
2018-12-17 15:48 ` Michal Hocko
2018-12-18 14:44 ` Wei Yang
2018-12-18 20:46 ` [PATCH v2] " Wei Yang
2018-12-18 21:14 ` David Hildenbrand
2018-12-18 21:49 ` Wei Yang
2018-12-18 22:18 ` David Hildenbrand
2018-12-18 23:29 ` Oscar Salvador
2018-12-19 9:51 ` Michal Hocko
2018-12-19 9:57 ` Oscar Salvador
2018-12-19 13:53 ` Wei Yang
2018-12-19 14:13 ` Michal Hocko
2018-12-19 14:33 ` Wei Yang [this message]
2018-12-19 14:39 ` Michal Hocko
2018-12-20 15:58 ` Wei Yang
2018-12-20 16:23 ` Michal Hocko
2018-12-21 3:37 ` Wei Yang
2018-12-19 13:29 ` Wei Yang
2018-12-19 13:40 ` Michal Hocko
2018-12-19 13:56 ` Wei Yang
2018-12-19 14:12 ` Michal Hocko
2018-12-19 14:41 ` Wei Yang
2018-12-19 10:05 ` Michal Hocko
2018-12-21 17:02 ` [PATCH v3] mm: remove extra drain pages on pcp list Wei Yang
2018-12-21 17:02 ` Wei Yang
2019-01-03 13:56 ` Michal Hocko
2019-01-05 23:27 ` Wei Yang
2019-01-05 23:31 ` [PATCH v4] " Wei Yang
2019-01-05 23:31 ` Wei Yang
2019-01-07 11:34 ` David Hildenbrand
2019-01-08 9:10 ` Oscar Salvador
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=20181219143327.wdsufbn2oh6ygnne@master \
--to=richard.weiyang@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
/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