From: Xishi Qiu <qiuxishi@huawei.com> To: Vlastimil Babka <vbabka@suse.cz> Cc: <linux-mm@kvack.org>, Johannes Weiner <hannes@cmpxchg.org>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, David Rientjes <rientjes@google.com>, Mel Gorman <mgorman@techsingularity.net>, <linux-kernel@vger.kernel.org>, <kernel-team@fb.com> Subject: Re: [PATCH v2 04/10] mm, page_alloc: count movable pages when stealing from pageblock Date: Wed, 15 Feb 2017 19:56:40 +0800 [thread overview] Message-ID: <58A441F8.9060909@huawei.com> (raw) In-Reply-To: <810cd21a-070b-c6ed-68f7-1b065b270568@suse.cz> On 2017/2/15 18:47, Vlastimil Babka wrote: > On 02/14/2017 11:07 AM, Xishi Qiu wrote: >> On 2017/2/11 1:23, Vlastimil Babka wrote: >> >>> When stealing pages from pageblock of a different migratetype, we count how >>> many free pages were stolen, and change the pageblock's migratetype if more >>> than half of the pageblock was free. This might be too conservative, as there >>> might be other pages that are not free, but were allocated with the same >>> migratetype as our allocation requested. >>> >>> While we cannot determine the migratetype of allocated pages precisely (at >>> least without the page_owner functionality enabled), we can count pages that >>> compaction would try to isolate for migration - those are either on LRU or >>> __PageMovable(). The rest can be assumed to be MIGRATE_RECLAIMABLE or >>> MIGRATE_UNMOVABLE, which we cannot easily distinguish. This counting can be >>> done as part of free page stealing with little additional overhead. >>> >>> The page stealing code is changed so that it considers free pages plus pages >>> of the "good" migratetype for the decision whether to change pageblock's >>> migratetype. >>> >>> The result should be more accurate migratetype of pageblocks wrt the actual >>> pages in the pageblocks, when stealing from semi-occupied pageblocks. This >>> should help the efficiency of page grouping by mobility. >>> >>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> >> >> Hi Vlastimil, >> >> How about these two changes? >> >> 1. If we steal some free pages, we will add these page at the head of start_migratetype >> list, it will cause more fixed, because these pages will be allocated more easily. > > What do you mean by "more fixed" here? > >> So how about use list_move_tail instead of list_move? > > Hmm, not sure if it can make any difference. We steal because the lists > are currently empty (at least for the order we want), so it shouldn't > matter if we add to head or tail. > Hi Vlastimil, Please see the following case, I am not sure if it is right. MIGRATE_MOVABLE order: 0 1 2 3 4 5 6 7 8 9 10 free num: 1 1 1 1 1 1 1 1 1 1 0 // one page(e.g. page A) was allocated before MIGRATE_UNMOVABLE order: 0 1 2 3 4 5 6 7 8 9 10 free num: x x x x 0 0 0 0 0 0 0 // we want order=4, so steal from MIGRATE_MOVABLE We alloc order=4 in MIGRATE_UNMOVABLE, then it will fallback to steal pages from MIGRATE_MOVABLE, and we will move free pages form MIGRATE_MOVABLE list to MIGRATE_UNMOVABLE list. List of order 4-9 in MIGRATE_UNMOVABLE is empty, so add head or tail is the same. But order 0-3 is not empty, so if we add to the head, we will allocate pages which stolen from MIGRATE_MOVABLE first later. So we will have less chance to make a large block(order=10) when the one page(page A) free again. Also we will split order=9 which from MIGRATE_MOVABLE to alloc order=4 in expand(), so if we add to the head, we will allocate pages which split from order=9 first later. So we will have less chance to make a large block(order=9) when the order=4 page free again. >> __rmqueue_fallback >> steal_suitable_fallback >> move_freepages_block >> move_freepages >> list_move >> >> 2. When doing expand() - list_add(), usually the list is empty, but in the >> following case, the list is not empty, because we did move_freepages_block() >> before. >> >> __rmqueue_fallback >> steal_suitable_fallback >> move_freepages_block // move to the list of start_migratetype >> expand // split the largest order >> list_add // add to the list of start_migratetype >> >> So how about use list_add_tail instead of list_add? Then we can merge the large >> block again as soon as the page freed. > > Same here. The lists are not empty, but contain probably just the pages > from our stolen pageblock. It shouldn't matter how we order them within > the same block. > > So maybe it could make some difference for higher-order allocations, but > it's unclear to me. Making e.g. expand() more complex with a flag to > tell it the head vs tail add could mean extra overhead in allocator fast > path that would offset any gains. > >> Thanks, >> Xishi Qiu >> > > > . >
WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com> To: Vlastimil Babka <vbabka@suse.cz> Cc: linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, David Rientjes <rientjes@google.com>, Mel Gorman <mgorman@techsingularity.net>, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 04/10] mm, page_alloc: count movable pages when stealing from pageblock Date: Wed, 15 Feb 2017 19:56:40 +0800 [thread overview] Message-ID: <58A441F8.9060909@huawei.com> (raw) In-Reply-To: <810cd21a-070b-c6ed-68f7-1b065b270568@suse.cz> On 2017/2/15 18:47, Vlastimil Babka wrote: > On 02/14/2017 11:07 AM, Xishi Qiu wrote: >> On 2017/2/11 1:23, Vlastimil Babka wrote: >> >>> When stealing pages from pageblock of a different migratetype, we count how >>> many free pages were stolen, and change the pageblock's migratetype if more >>> than half of the pageblock was free. This might be too conservative, as there >>> might be other pages that are not free, but were allocated with the same >>> migratetype as our allocation requested. >>> >>> While we cannot determine the migratetype of allocated pages precisely (at >>> least without the page_owner functionality enabled), we can count pages that >>> compaction would try to isolate for migration - those are either on LRU or >>> __PageMovable(). The rest can be assumed to be MIGRATE_RECLAIMABLE or >>> MIGRATE_UNMOVABLE, which we cannot easily distinguish. This counting can be >>> done as part of free page stealing with little additional overhead. >>> >>> The page stealing code is changed so that it considers free pages plus pages >>> of the "good" migratetype for the decision whether to change pageblock's >>> migratetype. >>> >>> The result should be more accurate migratetype of pageblocks wrt the actual >>> pages in the pageblocks, when stealing from semi-occupied pageblocks. This >>> should help the efficiency of page grouping by mobility. >>> >>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> >> >> Hi Vlastimil, >> >> How about these two changes? >> >> 1. If we steal some free pages, we will add these page at the head of start_migratetype >> list, it will cause more fixed, because these pages will be allocated more easily. > > What do you mean by "more fixed" here? > >> So how about use list_move_tail instead of list_move? > > Hmm, not sure if it can make any difference. We steal because the lists > are currently empty (at least for the order we want), so it shouldn't > matter if we add to head or tail. > Hi Vlastimil, Please see the following case, I am not sure if it is right. MIGRATE_MOVABLE order: 0 1 2 3 4 5 6 7 8 9 10 free num: 1 1 1 1 1 1 1 1 1 1 0 // one page(e.g. page A) was allocated before MIGRATE_UNMOVABLE order: 0 1 2 3 4 5 6 7 8 9 10 free num: x x x x 0 0 0 0 0 0 0 // we want order=4, so steal from MIGRATE_MOVABLE We alloc order=4 in MIGRATE_UNMOVABLE, then it will fallback to steal pages from MIGRATE_MOVABLE, and we will move free pages form MIGRATE_MOVABLE list to MIGRATE_UNMOVABLE list. List of order 4-9 in MIGRATE_UNMOVABLE is empty, so add head or tail is the same. But order 0-3 is not empty, so if we add to the head, we will allocate pages which stolen from MIGRATE_MOVABLE first later. So we will have less chance to make a large block(order=10) when the one page(page A) free again. Also we will split order=9 which from MIGRATE_MOVABLE to alloc order=4 in expand(), so if we add to the head, we will allocate pages which split from order=9 first later. So we will have less chance to make a large block(order=9) when the order=4 page free again. >> __rmqueue_fallback >> steal_suitable_fallback >> move_freepages_block >> move_freepages >> list_move >> >> 2. When doing expand() - list_add(), usually the list is empty, but in the >> following case, the list is not empty, because we did move_freepages_block() >> before. >> >> __rmqueue_fallback >> steal_suitable_fallback >> move_freepages_block // move to the list of start_migratetype >> expand // split the largest order >> list_add // add to the list of start_migratetype >> >> So how about use list_add_tail instead of list_add? Then we can merge the large >> block again as soon as the page freed. > > Same here. The lists are not empty, but contain probably just the pages > from our stolen pageblock. It shouldn't matter how we order them within > the same block. > > So maybe it could make some difference for higher-order allocations, but > it's unclear to me. Making e.g. expand() more complex with a flag to > tell it the head vs tail add could mean extra overhead in allocator fast > path that would offset any gains. > >> Thanks, >> Xishi Qiu >> > > > . > -- 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:[~2017-02-15 11:56 UTC|newest] Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-10 17:23 [PATCH v2 00/10] try to reduce fragmenting fallbacks Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-10 17:23 ` [PATCH v2 01/10] mm, compaction: reorder fields in struct compact_control Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:49 ` Mel Gorman 2017-02-13 10:49 ` Mel Gorman 2017-02-14 16:33 ` Johannes Weiner 2017-02-14 16:33 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 02/10] mm, compaction: remove redundant watermark check in compact_finished() Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:49 ` Mel Gorman 2017-02-13 10:49 ` Mel Gorman 2017-02-14 16:34 ` Johannes Weiner 2017-02-14 16:34 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 03/10] mm, page_alloc: split smallest stolen page in fallback Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:51 ` Mel Gorman 2017-02-13 10:51 ` Mel Gorman 2017-02-13 10:54 ` Vlastimil Babka 2017-02-13 10:54 ` Vlastimil Babka 2017-02-14 16:59 ` Johannes Weiner 2017-02-14 16:59 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 04/10] mm, page_alloc: count movable pages when stealing from pageblock Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:53 ` Mel Gorman 2017-02-13 10:53 ` Mel Gorman 2017-02-14 10:07 ` Xishi Qiu 2017-02-14 10:07 ` Xishi Qiu 2017-02-15 10:47 ` Vlastimil Babka 2017-02-15 10:47 ` Vlastimil Babka 2017-02-15 11:56 ` Xishi Qiu [this message] 2017-02-15 11:56 ` Xishi Qiu 2017-02-17 16:21 ` Vlastimil Babka 2017-02-17 16:21 ` Vlastimil Babka 2017-02-14 18:10 ` Johannes Weiner 2017-02-14 18:10 ` Johannes Weiner 2017-02-17 16:09 ` Vlastimil Babka 2017-02-17 16:09 ` Vlastimil Babka 2017-02-10 17:23 ` [PATCH v2 05/10] mm, compaction: change migrate_async_suitable() to suitable_migration_source() Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:53 ` Mel Gorman 2017-02-13 10:53 ` Mel Gorman 2017-02-14 18:12 ` Johannes Weiner 2017-02-14 18:12 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 06/10] mm, compaction: add migratetype to compact_control Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:53 ` Mel Gorman 2017-02-13 10:53 ` Mel Gorman 2017-02-14 18:15 ` Johannes Weiner 2017-02-14 18:15 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 07/10] mm, compaction: restrict async compaction to pageblocks of same migratetype Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:56 ` Mel Gorman 2017-02-13 10:56 ` Mel Gorman 2017-02-14 20:10 ` Johannes Weiner 2017-02-14 20:10 ` Johannes Weiner 2017-02-17 16:32 ` Vlastimil Babka 2017-02-17 16:32 ` Vlastimil Babka 2017-02-17 17:39 ` Johannes Weiner 2017-02-17 17:39 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 08/10] mm, compaction: finish whole pageblock to reduce fragmentation Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:57 ` Mel Gorman 2017-02-13 10:57 ` Mel Gorman 2017-02-16 11:44 ` Johannes Weiner 2017-02-16 11:44 ` Johannes Weiner 2017-02-10 17:23 ` [RFC v2 09/10] mm, page_alloc: disallow migratetype fallback in fastpath Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-10 17:23 ` [RFC v2 10/10] mm, page_alloc: introduce MIGRATE_MIXED migratetype Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-03-08 2:16 ` Yisheng Xie 2017-03-08 2:16 ` Yisheng Xie 2017-03-08 7:07 ` Vlastimil Babka 2017-03-08 7:07 ` Vlastimil Babka 2017-03-13 2:16 ` Yisheng Xie 2017-03-13 2:16 ` Yisheng Xie 2017-02-13 11:07 ` [PATCH v2 00/10] try to reduce fragmenting fallbacks Mel Gorman 2017-02-13 11:07 ` Mel Gorman 2017-02-15 14:29 ` Vlastimil Babka 2017-02-15 14:29 ` Vlastimil Babka 2017-02-15 16:11 ` Vlastimil Babka 2017-02-15 16:11 ` Vlastimil Babka 2017-02-15 20:11 ` Vlastimil Babka 2017-02-15 20:11 ` Vlastimil Babka 2017-02-16 15:12 ` Vlastimil Babka 2017-02-16 15:12 ` Vlastimil Babka 2017-02-17 15:24 ` Vlastimil Babka 2017-02-17 15:24 ` Vlastimil Babka 2017-02-20 12:30 ` Vlastimil Babka 2017-02-20 12:30 ` Vlastimil Babka 2017-02-23 16:01 ` Mel Gorman 2017-02-23 16:01 ` Mel Gorman
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=58A441F8.9060909@huawei.com \ --to=qiuxishi@huawei.com \ --cc=hannes@cmpxchg.org \ --cc=iamjoonsoo.kim@lge.com \ --cc=kernel-team@fb.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=rientjes@google.com \ --cc=vbabka@suse.cz \ /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: linkBe 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.