On 02/03/2015 04:00 PM, Joonsoo Kim wrote: > 2015-02-03 18:05 GMT+09:00 Vlastimil Babka <vbabka@xxxxxxx>: >> On 02/03/2015 07:49 AM, Joonsoo Kim wrote: >>> On Mon, Jan 19, 2015 at 11:05:15AM +0100, Vlastimil Babka wrote: >>> >>> Hello, >>> >>> I don't have any elegant idea, but, have some humble opinion. >>> >>> The point is that migrate scanner should scan whole zone. >>> Although your pivot approach makes some sense and it can scan whole zone, >>> it could cause back and forth migration in a very short term whenever >>> both scanners get toward and passed each other. >> >> I don't understand the scenario you suggest? The scanners don't overlap in any >> single run, that doesn't change. If they meet, compaction terminates. They can >> "overlap" if you compare the current run with previous run, after pivot change. > > Yeah, I mean this case. > > I think that we should regard single run as whole zone scan rather than just > terminating criteria we have artificially defined and try to avoid > back and forth > problem as much as possible in this scale. Not overlapping in a single run you > mentioned doesn't solve this problem in this scale. > >> The it's true that e.g. migration scanner will operate on pageblocks where the >> free scanner has operated on previously. But pivot changes are only done after >> the full defer cycle, which is not short term. > > I don't think it's not short term. After successful run, if next high > order request > comes immediately, migrate scanner will immediately restart at the position > where previous free scanner has operated. Ah, I think I see where the misunderstanding comes from now. So to clarify, let's consider 1. single compaction run - single invocation of compact_zone(). It can start from cached pfn's from previous run, or zone boundaries (or pivot, after this series), and terminate with scanners meeting or not meeting. 2. full zone compaction - consists one or more compaction runs, where the first run starts at boundaries (pivot). It ends when scanners meet - compact_finished() returns COMPACT_COMPLETE 3. compaction after full defer cycle - this is full zone compaction, where compaction_restarting() returns true in its first run My understanding is that you think pivot changing occurs after each full zone compaction (definition 2), but in fact it occurs only each defer cycle (definition 3). See patch 5 for detailed reasoning. I don't think it's short term. It means full zone compactions (def 2) already failed many times and then was deferred for further time, using the same unchanged pivot. I think any of the alternatives you suggested below where migrate scanner processes whole zone during full zone compaction (2), would necessarily result in shorter-term back and forth migration than this scheme. On the other hand, the pivot changing proposed here might be too long-term. But it's a first attempt, and the frequency can be further tuned. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>