All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, willy@infradead.org
Subject: Re: [PATCH 2/2] mm/migrate_device: further convert migrate_device_finalize() to folios
Date: Thu, 15 Feb 2024 09:45:16 +1100	[thread overview]
Message-ID: <8734tu7jbe.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <20240214202055.77776-2-sidhartha.kumar@oracle.com>


Sidhartha Kumar <sidhartha.kumar@oracle.com> writes:

> Use folio api functions from the already defined src and dst folio
> variables.
>
> Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
> ---
>  mm/migrate_device.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index 9152a329b0a68..a48d5cdb28553 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -843,17 +843,17 @@ void migrate_device_finalize(unsigned long *src_pfns,
>  		remove_migration_ptes(src, dst, false);
>  		folio_unlock(src);
>  
> -		if (is_zone_device_page(page))
> -			put_page(page);
> +		if (folio_is_zone_device(src))
> +			folio_put(src);
>  		else
> -			putback_lru_page(page);
> +			folio_putback_lru(src);
>  
>  		if (newpage != page) {
> -			unlock_page(newpage);
> -			if (is_zone_device_page(newpage))
> -				put_page(newpage);

Defining migrate_pfn_to_folio() would also allow the removal of the
newpage and page variables entirely which I think would make this
clearer.

As an aside is there any motivation for making these changes other than
as a general cleanup? I ask only because I have been looking at allowing
device pages with order > 0 so have some of these clean-ups in a local
tree as they're a pre-requisite for that.

 - Alistair

> +			folio_unlock(dst);
> +			if (folio_is_zone_device(dst))
> +				folio_put(dst);
>  			else
> -				putback_lru_page(newpage);
> +				folio_putback_lru(dst);
>  		}
>  	}
>  }



  reply	other threads:[~2024-02-14 22:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 20:20 [PATCH 1/2] mm/migrate_device: further convert migrate_device_unmap() to folios Sidhartha Kumar
2024-02-14 20:20 ` [PATCH 2/2] mm/migrate_device: further convert migrate_device_finalize() " Sidhartha Kumar
2024-02-14 22:45   ` Alistair Popple [this message]
2024-02-14 23:10     ` Sidhartha Kumar
2024-02-15  0:58       ` Alistair Popple
2024-02-14 22:38 ` [PATCH 1/2] mm/migrate_device: further convert migrate_device_unmap() " Alistair Popple
2024-02-15  4:08   ` Matthew Wilcox
2024-02-16  2:21     ` Alistair Popple

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=8734tu7jbe.fsf@nvdebian.thelocal \
    --to=apopple@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sidhartha.kumar@oracle.com \
    --cc=willy@infradead.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.