From: Oscar Salvador <osalvador@suse.de>
To: Michal Hocko <mhocko@suse.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Muchun Song <songmuchun@bytedance.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/5] mm,compaction: Let isolate_migratepages_{range,block} return error codes
Date: Fri, 19 Mar 2021 10:57:47 +0100 [thread overview]
Message-ID: <20210319095742.GA6409@linux> (raw)
In-Reply-To: <YFM7VPo06EuzfN4b@dhcp22.suse.cz>
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
next prev parent reply other threads:[~2021-03-19 9:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 11:12 [PATCH v5 0/5] Make alloc_contig_range handle Hugetlb pages Oscar Salvador
2021-03-17 11:12 ` [PATCH v5 1/5] mm,page_alloc: Bail out earlier on -ENOMEM in alloc_contig_migrate_range Oscar Salvador
2021-03-17 14:05 ` Michal Hocko
2021-03-17 14:42 ` David Hildenbrand
2021-03-17 14:49 ` Michal Hocko
2021-03-18 11:04 ` Oscar Salvador
2021-03-18 11:37 ` Michal Hocko
2021-03-17 11:12 ` [PATCH v5 2/5] mm,compaction: Let isolate_migratepages_{range,block} return error codes Oscar Salvador
2021-03-17 14:12 ` Michal Hocko
2021-03-17 14:38 ` Oscar Salvador
2021-03-17 14:59 ` Michal Hocko
2021-03-18 9:50 ` Vlastimil Babka
2021-03-18 10:22 ` Michal Hocko
2021-03-18 11:10 ` Vlastimil Babka
2021-03-18 11:36 ` Michal Hocko
2021-03-19 9:57 ` Oscar Salvador [this message]
2021-03-19 10:14 ` Vlastimil Babka
2021-03-19 10:26 ` Oscar Salvador
2021-03-17 11:12 ` [PATCH v5 3/5] mm: Make alloc_contig_range handle free hugetlb pages Oscar Salvador
2021-03-17 14:22 ` Michal Hocko
2021-03-17 11:12 ` [PATCH v5 4/5] mm: Make alloc_contig_range handle in-use " Oscar Salvador
2021-03-17 14:26 ` Michal Hocko
2021-03-18 8:54 ` Oscar Salvador
2021-03-18 9:29 ` Michal Hocko
2021-03-18 9:59 ` Oscar Salvador
2021-03-18 10:12 ` Michal Hocko
2021-03-17 11:12 ` [PATCH v5 5/5] mm,page_alloc: Drop unnecessary checks from pfn_range_valid_contig Oscar Salvador
2021-03-17 11:15 ` David Hildenbrand
2021-03-17 14:31 ` Michal Hocko
2021-03-17 14:36 ` David Hildenbrand
2021-03-17 15:03 ` Michal Hocko
2021-03-18 8:44 ` Oscar Salvador
2021-03-18 8:55 ` Michal Hocko
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=20210319095742.GA6409@linux \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=songmuchun@bytedance.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: link
Be 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.