Messages in this thread | | | Subject | Re: [PATCH v2 4/5] mm, kswapd: replace kswapd compaction with waking up kcompactd | From | Vlastimil Babka <> | Date | Wed, 2 Mar 2016 15:09:33 +0100 |
| |
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?
> 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.
| |