Received-SPF: pass (google.com: domain of linux-kernel+bounces-67973-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
References: <20240214202055.77776-1-sidhartha.kumar@oracle.com>
 <877cj67jn3.fsf@nvdebian.thelocal> <Zc2OVIEVe87WCruV@casper.infradead.org>
User-agent: mu4e 1.10.8; emacs 29.1
From: Alistair Popple <apopple@nvidia.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>,
 linux-kernel@vger.kernel.org, linux-mm@kvack.org,
 akpm@linux-foundation.org
Subject: Re: [PATCH 1/2] mm/migrate_device: further convert
 migrate_device_unmap() to folios
Date: Fri, 16 Feb 2024 13:21:26 +1100
In-reply-to: <Zc2OVIEVe87WCruV@casper.infradead.org>
Message-ID: <877cj5du80.fsf@nvdebian.thelocal>
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?bwQogqoiCZWznfYfEfyhH0xFw3Oi6Gq8ccqG8TabZCpqGusNEMp3w03UhUEX?=
 =?us-ascii?Q?1Zpz4zNuWwVzm7V+rVwQVcmfZopSmeDHrvo21azgLEadXM9x1NzRPBnOvm5y?=
 =?us-ascii?Q?ODmfaAm5yRF+8Nng3oHhHR9o3T2xG2CvNeYZwMg2fO77DLGtyVHxY9xuoQX6?=
 =?us-ascii?Q?YmHbGUixVbK4QqpQNEyYyfLIBTRFzr51MWqKZAou5VSC7//BA4e6U2QF/mYQ?=
 =?us-ascii?Q?kAsxc6YA3nu88+ICHPWg7ssqNkxIdsrjRPpLa3mIpSCEtvJa1Pbm//9IR3T3?=
 =?us-ascii?Q?Ys2viH296VhObslAAUUO7uy2vCKtAhTwSL1m1cnIyu4fY8WMQpDo3Jo+1xa3?=
 =?us-ascii?Q?57g0eSrGy/Y2NHMC98m3p5t8V6zzwefmYqtR5p6i4GTXwj8tN23ZNWU3YlDz?=
 =?us-ascii?Q?m3GRPjQqTXT4zPwgwbqJLQsERZ7e174ZslLPjF+S/cRAqugdjSa8i28EXS9e?=
 =?us-ascii?Q?lRvmzZdkf1Lr2MN0+zdSAJ3yY9VKLooM3bvzZbDiWFQhqv9+LXCaRMGRyb6I?=
 =?us-ascii?Q?6Z+ruYxFM9+NoUp517EeEcR8P7ENvhtmrdQBOTa+OePGxs6kCsFOYUeU36Mn?=
 =?us-ascii?Q?E5alRjEgmbsbeKyGvTVl96Po3laTe2swIns8CVPIIpdeU0vioeYwD5VbnD7S?=
 =?us-ascii?Q?4ct8eUfw6/WVs5scBNlg6MNX5WLUYpDJH18y7wBL3kE9ZLeGZyXGuKU6zyTh?=
 =?us-ascii?Q?jzHbXegd9ajSp1RSMELEjj9/15czBA7bI77dZs6o7MTKkZqWWRkKiLfbiBfR?=
 =?us-ascii?Q?xuVHgJhx9WO4ozmfSK8feLe2f+jCi/IZz9Cl7spY14ByrEyFe71WovOO5UTf?=
 =?us-ascii?Q?k5uXVUNjCGDylfCYWrn+ay6JmyQIFPUDAtiyxiK9FMFDqDFLYsqs4JLxANii?=
 =?us-ascii?Q?BIrON/2nOTCvBbAOqehUFrLa+jIaRP2X6Bi+mYeN5OLvKMBrah/hQ92+6/rs?=
 =?us-ascii?Q?2bMm1UxoEIgOcdRMXwLAwvpHwqiyQnX6Jvspw7z6fCZcxq83wIYgtr3kx6WG?=
 =?us-ascii?Q?QEdAKtv3vJdkdlf1yGgxf40Thh7J3YRO5TDHsW8yy/VuSm9mvdzWVcneMnTR?=
 =?us-ascii?Q?bKtjBcxfiYpo0oHgZ7rQZEkhtmIexfwqn8WGL0mabWGk4CVhoc4gd/D6aZvR?=
 =?us-ascii?Q?aVItd5qogMDgALvwu+7waZmOap6Pdpl34VQxxGKizsykioZKvN0VRmSnJBwB?=
 =?us-ascii?Q?DbwSWwxKZ9Toje8BkQ0VioLmRykG7kYsyICKfj4AGMCsit68wokaAujDhX6/?=
 =?us-ascii?Q?xVli6k1zm+jJKzNMMem9LpYezoexGga9D4qpQt4/U6PI7xmxZ3C+PS/ODKfC?=
 =?us-ascii?Q?2YbodgetTV+a7vr8neSBJcg445PYij0vXUtDxY/27WjOpGta+60epFQ7c1f9?=
 =?us-ascii?Q?d0yc7c9O7a1gYuOhqH/CYPgcmbitcLCaO/0GiOzbR5LVWmVPvvXa9Wh1qig1?=
 =?us-ascii?Q?oibL3UHh69S4V3G+TFuwYZ72ET4QXfv1Jm/xjxqbWzsyzWAMaI/M/Nof+gus?=
 =?us-ascii?Q?KWlu1VWtZGCwJezTpPyjFMfHHzBv98zKzPZakqtfD5bjL5V/z4P7IVfw630v?=
 =?us-ascii?Q?snGKoW10DgzeillMZiO2uc6vjFeaJpG7khG8BPLU?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 17f46a72-ab14-44cf-1148-08dc2e960b73
X-MS-Exchange-CrossTenant-AuthSource: DS0PR12MB7726.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2024 02:21:55.3567
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: C0p8L450afpBLCh874WsYWBAt7kkrN/+xdY00O8tEi5ur9C8CuC4udetfRQlJeRjXjavGJh46SE3eHKi7tlI/g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8503


Matthew Wilcox <willy@infradead.org> writes:

> On Thu, Feb 15, 2024 at 09:38:42AM +1100, Alistair Popple wrote:
>> > +++ b/mm/migrate_device.c
>> > @@ -377,33 +377,33 @@ static unsigned long migrate_device_unmap(unsigned long *src_pfns,
>> >  			continue;
>> >  		}
>> >  
>> > +		folio = page_folio(page);
>> 
>> Instead of open coding the migrate pfn to folio conversion I think we
>> should define a migrate_pfn_to_folio() and get rid of the intermediate
>> local variable. This would also allow a minor clean up to the final for
>> loop in migrate_device_unmap().
>
> I think we should stop passing pfns into migrate_device_unmap().
> Passing an array of folios would make more sense to every function
> involved, afaict.  Maybe I overlooked something ...

Note these are migration pfns. The main reason we do this is we need to
track and possibly modify some per-pfn state around between all these
functions during the migration process.

> Also, have you had any thoughts on whether device memory is a type of
> folio like anon/file memory, or is it its own type?

I don't quite follow what the precise distinction there is but I think
of them as normal pages/folios like anon/file memory folios because we
rely on the same kernel paths and rules to manage them (ie. they get
refcounted the same as normal pages, CoWed, etc.). Currently we only
allow these to be mapped into private/anon VMAs but I have an
experiemental series to allow them to be mapped into shared or
filebacked VMAs which basically involves putting them into the
page-cache.

Most drivers also have a 1:1 mapping of struct page to a physical page
of device memory and due to all the folio work it's fairly easy to
extend this to support higher order folios. I will try and post the
first half of my changes that convert all the page based handling to
folios. I got caught up trying figuring out a sane API for
splitting/merging during migration but maybe I should just post the
folio conversion as a simpler first step.