From: Joonsoo Kim <js1304@gmail.com> To: Vlastimil Babka <vbabka@suse.cz> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>, Linux Memory Management List <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Andrea Arcangeli <aarcange@redhat.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@techsingularity.net>, David Rientjes <rientjes@google.com>, Michal Hocko <mhocko@suse.com>, Johannes Weiner <hannes@cmpxchg.org> Subject: Re: [PATCH v2 4/5] mm, kswapd: replace kswapd compaction with waking up kcompactd Date: Wed, 2 Mar 2016 23:22:11 +0900 [thread overview] Message-ID: <CAAmzW4PGgYkL9xnCXgSQ=8kW0sJkaYyrxenb_XKHcW1wDGMEyw@mail.gmail.com> (raw) In-Reply-To: <56D6F41D.9080107@suse.cz> 2016-03-02 23:09 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>: > On 03/02/2016 02:57 PM, Joonsoo Kim wrote: >> >> 2016-03-02 19:04 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>: >>> >>> On 03/02/2016 07:33 AM, Joonsoo Kim wrote: >>>> >>>> >>>> >>>> Why you did the test with THP? THP interferes result of main test so >>>> it would be better not to enable it. >>> >>> >>> >>> Hmm I've always left it enabled. It makes for a more realistic >>> interference >>> and would also show unintended regressions in that closely related area. >> >> >> But, it makes review hard because complex analysis is needed to >> understand the result. >> >> Following is the example. >> >> "The compaction stalls >> (direct compaction) in the interfering kernel builds (probably THP's) also >> decreased somewhat to kcompactd activity, yet THP alloc successes improved >> a >> bit." >> >> So, why do we need this comment to understand effect of this patch? If you >> did >> a test without THP, it would not be necessary. > > > I see. Next time I'll do a run with THP disabled. > >>>> And, this patch increased compaction activity (10 times for migrate >>>> scanned) >>>> may be due to resetting skip block information. >>> >>> >>> >>> Note that kswapd compaction activity was completely non-existent for >>> reasons >>> outlined in the changelog. >>>> >>>> Isn't is better to disable it >>>> for this patch to work as similar as possible that kswapd does and >>>> re-enable it >>>> on next patch? If something goes bad, it can simply be reverted. >>>> >>>> Look like it is even not mentioned in the description. >>> >>> >>> >>> Yeah skip block information is discussed in the next patch, which >>> mentions >>> that it's being reset and why. I think it makes more sense, as when >>> kswapd >> >> >> Yes, I know. >> What I'd like to say here is that you need to care current_is_kswapd() in >> this patch. This patch unintentionally change the back ground compaction >> thread >> behaviour to restart compaction by every 64 trials because calling >> curret_is_kswapd() > >> by kcompactd would return false and is treated as direct reclaim. > > Oh, you mean this path to reset the skip bits. I see. But if skip bits are > already reset by kswapd when waking kcompactd, then effect of another (rare) > reset in kcompactd itself will be minimal? If you care current_is_kswapd() in this patch properly (properly means change like "current_is_kcompactd()), reset in kswapd would not happen because, compact_blockskip_flush would not be set by kcompactd. In this case, patch 5 would have it's own meaning so cannot be folded. Thanks. >> Result of patch 4 >> and patch 5 would be same. > > > It's certainly possible to fold patch 5 into 4. I posted them separately > mainly to make review more feasible. But the differences in results are > already quite small. >
WARNING: multiple messages have this Message-ID (diff)
From: Joonsoo Kim <js1304@gmail.com> To: Vlastimil Babka <vbabka@suse.cz> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>, Linux Memory Management List <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Andrea Arcangeli <aarcange@redhat.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@techsingularity.net>, David Rientjes <rientjes@google.com>, Michal Hocko <mhocko@suse.com>, Johannes Weiner <hannes@cmpxchg.org> Subject: Re: [PATCH v2 4/5] mm, kswapd: replace kswapd compaction with waking up kcompactd Date: Wed, 2 Mar 2016 23:22:11 +0900 [thread overview] Message-ID: <CAAmzW4PGgYkL9xnCXgSQ=8kW0sJkaYyrxenb_XKHcW1wDGMEyw@mail.gmail.com> (raw) In-Reply-To: <56D6F41D.9080107@suse.cz> 2016-03-02 23:09 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>: > On 03/02/2016 02:57 PM, Joonsoo Kim wrote: >> >> 2016-03-02 19:04 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>: >>> >>> On 03/02/2016 07:33 AM, Joonsoo Kim wrote: >>>> >>>> >>>> >>>> Why you did the test with THP? THP interferes result of main test so >>>> it would be better not to enable it. >>> >>> >>> >>> Hmm I've always left it enabled. It makes for a more realistic >>> interference >>> and would also show unintended regressions in that closely related area. >> >> >> But, it makes review hard because complex analysis is needed to >> understand the result. >> >> Following is the example. >> >> "The compaction stalls >> (direct compaction) in the interfering kernel builds (probably THP's) also >> decreased somewhat to kcompactd activity, yet THP alloc successes improved >> a >> bit." >> >> So, why do we need this comment to understand effect of this patch? If you >> did >> a test without THP, it would not be necessary. > > > I see. Next time I'll do a run with THP disabled. > >>>> And, this patch increased compaction activity (10 times for migrate >>>> scanned) >>>> may be due to resetting skip block information. >>> >>> >>> >>> Note that kswapd compaction activity was completely non-existent for >>> reasons >>> outlined in the changelog. >>>> >>>> Isn't is better to disable it >>>> for this patch to work as similar as possible that kswapd does and >>>> re-enable it >>>> on next patch? If something goes bad, it can simply be reverted. >>>> >>>> Look like it is even not mentioned in the description. >>> >>> >>> >>> Yeah skip block information is discussed in the next patch, which >>> mentions >>> that it's being reset and why. I think it makes more sense, as when >>> kswapd >> >> >> Yes, I know. >> What I'd like to say here is that you need to care current_is_kswapd() in >> this patch. This patch unintentionally change the back ground compaction >> thread >> behaviour to restart compaction by every 64 trials because calling >> curret_is_kswapd() > >> by kcompactd would return false and is treated as direct reclaim. > > Oh, you mean this path to reset the skip bits. I see. But if skip bits are > already reset by kswapd when waking kcompactd, then effect of another (rare) > reset in kcompactd itself will be minimal? If you care current_is_kswapd() in this patch properly (properly means change like "current_is_kcompactd()), reset in kswapd would not happen because, compact_blockskip_flush would not be set by kcompactd. In this case, patch 5 would have it's own meaning so cannot be folded. Thanks. >> Result of patch 4 >> and patch 5 would be same. > > > It's certainly possible to fold patch 5 into 4. I posted them separately > mainly to make review more feasible. But the differences in results are > already quite small. > -- 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-02 14:22 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-02-08 13:38 [PATCH v2 0/5] introduce kcompactd and stop compacting in kswapd Vlastimil Babka 2016-02-08 13:38 ` Vlastimil Babka 2016-02-08 13:38 ` [PATCH v2 1/5] mm, kswapd: remove bogus check of balance_classzone_idx Vlastimil Babka 2016-02-08 13:38 ` Vlastimil Babka 2016-02-08 13:38 ` [PATCH v2 2/5] mm, compaction: introduce kcompactd Vlastimil Babka 2016-02-08 13:38 ` Vlastimil Babka 2016-03-02 6:09 ` Joonsoo Kim 2016-03-02 6:09 ` Joonsoo Kim 2016-03-02 12:25 ` Vlastimil Babka 2016-03-02 12:25 ` Vlastimil Babka 2016-02-08 13:38 ` [PATCH v2 3/5] mm, memory hotplug: small cleanup in online_pages() Vlastimil Babka 2016-02-08 13:38 ` Vlastimil Babka 2016-02-08 13:38 ` [PATCH v2 4/5] mm, kswapd: replace kswapd compaction with waking up kcompactd Vlastimil Babka 2016-02-08 13:38 ` Vlastimil Babka 2016-02-08 22:58 ` Andrew Morton 2016-02-08 22:58 ` Andrew Morton 2016-02-09 10:53 ` Vlastimil Babka 2016-02-09 10:53 ` Vlastimil Babka 2016-02-09 10:21 ` Vlastimil Babka 2016-02-09 10:21 ` Vlastimil Babka 2016-03-01 14:14 ` Vlastimil Babka 2016-03-01 14:14 ` Vlastimil Babka 2016-03-02 6:33 ` Joonsoo Kim 2016-03-02 6:33 ` Joonsoo Kim 2016-03-02 10:04 ` Vlastimil Babka 2016-03-02 10:04 ` Vlastimil Babka 2016-03-02 13:57 ` Joonsoo Kim 2016-03-02 13:57 ` Joonsoo Kim 2016-03-02 14:09 ` Vlastimil Babka 2016-03-02 14:09 ` Vlastimil Babka 2016-03-02 14:22 ` Joonsoo Kim [this message] 2016-03-02 14:22 ` Joonsoo Kim 2016-03-02 14:40 ` Vlastimil Babka 2016-03-02 14:40 ` Vlastimil Babka 2016-03-02 14:59 ` Joonsoo Kim 2016-03-02 14:59 ` Joonsoo Kim 2016-03-02 15:22 ` Vlastimil Babka 2016-03-02 15:22 ` Vlastimil Babka 2016-03-04 23:25 ` Andrew Morton 2016-03-04 23:25 ` Andrew Morton 2016-03-07 9:45 ` Vlastimil Babka 2016-03-07 9:45 ` Vlastimil Babka 2016-03-09 13:47 ` Vlastimil Babka 2016-03-09 13:47 ` Vlastimil Babka 2016-03-09 13:50 ` Vlastimil Babka 2016-03-09 13:50 ` Vlastimil Babka 2016-03-02 12:27 ` Vlastimil Babka 2016-03-02 12:27 ` Vlastimil Babka 2016-02-08 13:38 ` [PATCH v2 5/5] mm, compaction: adapt isolation_suitable flushing to kcompactd Vlastimil Babka 2016-02-08 13:38 ` Vlastimil Babka 2016-03-01 14:44 ` Vlastimil Babka 2016-03-01 14:44 ` Vlastimil Babka 2016-03-09 15:52 ` [PATCH v2 0/5] introduce kcompactd and stop compacting in kswapd Michal Hocko 2016-03-09 15:52 ` Michal Hocko 2016-03-10 8:38 ` Vlastimil Babka 2016-03-10 8:38 ` 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='CAAmzW4PGgYkL9xnCXgSQ=8kW0sJkaYyrxenb_XKHcW1wDGMEyw@mail.gmail.com' \ --to=js1304@gmail.com \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=iamjoonsoo.kim@lge.com \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=mhocko@suse.com \ --cc=riel@redhat.com \ --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.