On Thu, Mar 18, 2021 at 12:36:52PM +0100, Michal Hocko wrote:
> Yeah, makes sense. I am not a fan of the above form of documentation.
> Btw. maybe renaming the field would be even better, both from the
> intention and review all existing users. I would go with pfn_iter or
> something that wouldn't make it sound like migration specific.
Just to be sure we are on the same page, you meant something like the following
(wrt. comments):
/*
* compact_control is used to track pages being migrated and the free pages
* they are being migrated to during memory compaction. The free_pfn starts
* at the end of a zone and migrate_pfn begins at the start. Movable pages
* are moved to the end of a zone during a compaction run and the run
* completes when free_pfn <= migrate_pfn
*
* freepages: List of free pages to migrate to
* migratepages: List of pages that need to be migrated
* nr_freepages: Number of isolated free pages
...
*/
struct compact_control {
struct list_head freepages;
...
With the preface that I am not really familiar with compaction code:
About renaming the variable to something else, I wouldn't do it.
I see migrate_pfn being used in contexts where migration gets mentioned,
e.g:
/*
* Briefly search the free lists for a migration source that already has
* some free pages to reduce the number of pages that need migration
* before a pageblock is free.
*/
fast_find_migrateblock(struct compact_control *cc)
{
...
unsigned long pfn = cc->migrate_pfn;
}
isolate_migratepages()
/* Record where migration scanner will be restarted. */
So, I would either stick with it, or add a new 'iter_pfn'/'next_pfn_scan'
field if we feel the need to.
--
Oscar Salvador
SUSE L3
