All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Gregory Price <gourry.memverge@gmail.com>
Cc: <linux-mm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arch@vger.kernel.org>, <linux-api@vger.kernel.org>,
	<linux-cxl@vger.kernel.org>, <luto@kernel.org>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>,
	<dave.hansen@linux.intel.com>, <hpa@zytor.com>, <arnd@arndb.de>,
	<akpm@linux-foundation.org>, <x86@kernel.org>,
	Gregory Price <gregory.price@memverge.com>
Subject: Re: [RFC v2 3/5] mm/migrate: refactor add_page_for_migration for code re-use
Date: Mon, 2 Oct 2023 14:51:27 +0100	[thread overview]
Message-ID: <20231002145127.0000685e@Huawei.com> (raw)
In-Reply-To: <20230919230909.530174-4-gregory.price@memverge.com>

On Tue, 19 Sep 2023 19:09:06 -0400
Gregory Price <gourry.memverge@gmail.com> wrote:

> add_page_for_migration presently does two actions:
>   1) validates the page is present and migratable
>   2) isolates the page from LRU and puts it into the migration list
> 
> Break add_page_for_migration into 2 functions:
>   add_page_for_migration - isolate the page from LUR and add to list
>   add_virt_page_for_migration - validate the page and call the above
> 
> add_page_for_migration does not require the mm_struct and so can be
> re-used for a physical addressing version of move_pages
> 
> Signed-off-by: Gregory Price <gregory.price@memverge.com>

A few things inline.

> ---
>  mm/migrate.c | 83 +++++++++++++++++++++++++++++++---------------------
>  1 file changed, 50 insertions(+), 33 deletions(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index dbe436163d65..1123d841a7f1 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -2042,52 +2042,33 @@ static int do_move_pages_to_node(struct list_head *pagelist, int node)
>  }
>  
>  /*
> - * Resolves the given address to a struct page, isolates it from the LRU and
> - * puts it to the given pagelist.
> + * Isolates the page from the LRU and puts it into the given pagelist
>   * Returns:
>   *     errno - if the page cannot be found/isolated

Is found still meaningful for what is in here?

>   *     0 - when it doesn't have to be migrated because it is already on the
>   *         target node
>   *     1 - when it has been queued
>   */
> -static int add_page_for_migration(struct mm_struct *mm, const void __user *p,
> -		int node, struct list_head *pagelist, bool migrate_all)
> +static int add_page_for_migration(struct page *page, int node,
> +		struct list_head *pagelist, bool migrate_all)
>  {
> -	struct vm_area_struct *vma;
> -	unsigned long addr;
> -	struct page *page;
>  	int err;
>  	bool isolated;
>  
> -	mmap_read_lock(mm);
> -	addr = (unsigned long)untagged_addr_remote(mm, p);
> -
> -	err = -EFAULT;
> -	vma = vma_lookup(mm, addr);
> -	if (!vma || !vma_migratable(vma))
> -		goto out;
> -
> -	/* FOLL_DUMP to ignore special (like zero) pages */
> -	page = follow_page(vma, addr, FOLL_GET | FOLL_DUMP);
> -
> -	err = PTR_ERR(page);
> -	if (IS_ERR(page))
> -		goto out;
> -
>  	err = -ENOENT;
>  	if (!page)
>  		goto out;

As noted below - this check is now duplicated.  Might make sense
of course, but not obvious if it was intended.

>  
>  	if (is_zone_device_page(page))
> -		goto out_putpage;
> +		goto out;
>  
>  	err = 0;
>  	if (page_to_nid(page) == node)
> -		goto out_putpage;
> +		goto out;
>  
>  	err = -EACCES;
>  	if (page_mapcount(page) > 1 && !migrate_all)
> -		goto out_putpage;
> +		goto out;
>  
>  	if (PageHuge(page)) {
>  		if (PageHead(page)) {
> @@ -2101,7 +2082,7 @@ static int add_page_for_migration(struct mm_struct *mm, const void __user *p,
>  		isolated = isolate_lru_page(head);
>  		if (!isolated) {
>  			err = -EBUSY;
> -			goto out_putpage;
> +			goto out;
>  		}
>  
>  		err = 1;
> @@ -2110,12 +2091,48 @@ static int add_page_for_migration(struct mm_struct *mm, const void __user *p,
>  			NR_ISOLATED_ANON + page_is_file_lru(head),
>  			thp_nr_pages(head));
>  	}
> -out_putpage:
> -	/*
> -	 * Either remove the duplicate refcount from
> -	 * isolate_lru_page() or drop the page ref if it was
> -	 * not isolated.
> -	 */
> +out:
Given nothing to do here now, perhaps remove to early returns
as that may simplify some error paths.

> +	return err;
> +}
> +
> +/*
> + * Resolves the given address to a struct page, isolates it from the LRU and
> + * puts it to the given pagelist.
> + * Returns:
> + *     errno - if the page cannot be found/isolated
> + *     0 - when it doesn't have to be migrated because it is already on the
> + *         target node
> + *     1 - when it has been queued
> + */
> +static int add_virt_page_for_migration(struct mm_struct *mm,
> +		const void __user *p, int node, struct list_head *pagelist,
> +		bool migrate_all)
> +{
> +	struct vm_area_struct *vma;
> +	unsigned long addr;
> +	struct page *page;
> +	int err = -EFAULT;
> +
> +	mmap_read_lock(mm);
> +	addr = (unsigned long)untagged_addr_remote(mm, p);
> +
> +	vma = vma_lookup(mm, addr);
> +	if (!vma || !vma_migratable(vma))
> +		goto out;
> +
> +	/* FOLL_DUMP to ignore special (like zero) pages */
> +	page = follow_page(vma, addr, FOLL_GET | FOLL_DUMP);
> +
> +	err = PTR_ERR(page);
> +	if (IS_ERR(page))
> +		goto out;
> +
> +	err = -ENOENT;
> +	if (!page)
> +		goto out;

You do this here then again in add_page_for_migration().  Does it
need to be in both places?

> +
> +	err = add_page_for_migration(page, node, pagelist, migrate_all);
> +
>  	put_page(page);
>  out:
>  	mmap_read_unlock(mm);
> @@ -2211,7 +2228,7 @@ static int do_pages_move(struct mm_struct *mm, nodemask_t task_nodes,
>  		 * Errors in the page lookup or isolation are not fatal and we simply
>  		 * report them via status
>  		 */
> -		err = add_page_for_migration(mm, p, current_node, &pagelist,
> +		err = add_virt_page_for_migration(mm, p, current_node, &pagelist,
>  					     flags & MPOL_MF_MOVE_ALL);
>  
>  		if (err > 0) {


  reply	other threads:[~2023-10-02 13:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19 23:09 [RFC v2 0/5] move_phys_pages syscall Gregory Price
2023-09-19 23:09 ` [RFC v2 1/5] mm/migrate: fix do_pages_move for compat pointers Gregory Price
2023-09-20  9:36   ` Arnd Bergmann
2023-09-19 23:09 ` [RFC v2 2/5] mm/migrate: remove unused mm argument from do_move_pages_to_node Gregory Price
2023-10-02 13:44   ` Jonathan Cameron
2023-09-19 23:09 ` [RFC v2 3/5] mm/migrate: refactor add_page_for_migration for code re-use Gregory Price
2023-10-02 13:51   ` Jonathan Cameron [this message]
2023-09-19 23:09 ` [RFC v2 4/5] mm/migrate: Create move_phys_pages syscall Gregory Price
2023-09-20 11:47   ` kernel test robot
2023-09-25 14:22   ` kernel test robot
2023-09-26 17:44   ` kernel test robot
2023-10-02 14:07   ` Jonathan Cameron
2023-10-03 17:58     ` Gregory Price
2023-10-11 19:19   ` kernel test robot
2023-09-19 23:09 ` [RFC v2 5/5] ktest: sys_move_phys_pages ktest Gregory Price
2023-10-02 14:09   ` Jonathan Cameron
2023-09-19 23:09 ` [RFC] man/move_phys_pages: migrate pages based on physical address Gregory Price

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=20231002145127.0000685e@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=gourry.memverge@gmail.com \
    --cc=gregory.price@memverge.com \
    --cc=hpa@zytor.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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.