From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 748E575809; Wed, 27 May 2026 02:57:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779850675; cv=none; b=Cp3kQlMQEgtR4CtNauMP+DLnaOjblOQKvAo7HhlAi+xH+3clStmD0y705IlUyXwgx9MwNrmjs/0mS7+Z6Qfzj4SwL82D9mvyIiTfPHTS4hkCL8Lid2sW9vaxu3eckg181Kz5BLFbzWs8Qe27KjUG8zEOAcCqot7pywG32yTbn8Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779850675; c=relaxed/simple; bh=tSlQMcribIZ4iGewHDLK9PwuVuTUH7Sy2ZEJ1Gb1GiA=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=Kwb3C7Kgmfz7kzM5CPc1v7uZjzH6QRlIqhOkBzihg3WFWWoyIDuGuBbtsZKipdtwrsK6jdq8tT6OMQBs3Dcm8V/iheulajmVuAZoaSDRPSjeOm577R6YPWRzihaNhb2ZJJm7aV3s9NEbIZ0ep9FpUQJRGn1tt55l/Abc91wSqJA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=jRHumPzy; arc=none smtp.client-ip=113.46.200.224 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="jRHumPzy" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=OevDCY97IHfMWjohNiIYTqTRYr/bbPEe4iODaGzCseQ=; b=jRHumPzyfWCCF+pN7RD25xUqbdZBtJrU/LkkjWSghE/SDZVDQJHA1uf8sTeQQJb+pPrrVIriv BHuldCsnAcyzX2PDcp0+sXpNTRAcEZ1GyfXFQmgDwVeRSRjpiwTtY+Ft4brF9v9wA+TktkA6SrK uso67IalMfYGi4RTYZwkOak= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4gQDcX1Rg0z1cyQ9; Wed, 27 May 2026 10:50:04 +0800 (CST) Received: from kwepemr500001.china.huawei.com (unknown [7.202.194.229]) by mail.maildlp.com (Postfix) with ESMTPS id 70A6E40565; Wed, 27 May 2026 10:57:48 +0800 (CST) Received: from [10.174.179.248] (10.174.179.248) by kwepemr500001.china.huawei.com (7.202.194.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 27 May 2026 10:57:45 +0800 Message-ID: <9dbcf423-108b-40cd-80af-6b93f113599d@huawei.com> Date: Wed, 27 May 2026 10:57:45 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH mm-unstable RFC v4 0/7] mm: add huge pfnmap support for remap_pfn_range() To: Lorenzo Stoakes CC: Andrew Morton , Matthew Wilcox , David Hildenbrand , Juergen Gross , Jonathan Cameron , Will Deacon , Catalin Marinas , Peter Xu , Luiz Capitulino , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "Liam R . Howlett" , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Anshuman Khandual , Rohan McLure , Kevin Brodsky , Alistair Popple , Andrew Donnellan , Pasha Tatashin , Baoquan He , Thomas Huth , Coiby Xu , Dan Williams , Yu-cheng Yu , Lu Baolu , Conor Dooley , Rik van Riel , , , , , , , , References: <20260526145003.88445-1-yintirui@huawei.com> From: Yin Tirui In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemr500001.china.huawei.com (7.202.194.229) On 5/26/2026 11:33 PM, Lorenzo Stoakes wrote: > Allow me to be mildly pedantic (sorry :) > > One thing I'd like to highlight here is that remap_pfn_range() is, in the long > run, deprecated. > > mmap_prepare callbacks will indicate a PFN remap mmap_action, which will do the > heavy lifting (see [0]). Thanks, I missed that mmap_action_remap() may also reach the same common PFN remap path. > So perhaps worth referring to 'PFN remapping' or something? > > (Since we already have mmap_prepare() in use, it's also kinda inaccurate to > say remap_pfn_range() :) Agreed, describing this as remap_pfn_range()support is indeed inaccurate. I'll reword it. > > [0]: https://www.kernel.org/doc/html/next/filesystems/mmap_prepare.html > > Sorry, this is pretty nitpicky :) Not at all, this is really helpful. > > Cheers, Lorenzo > -- Yin Tirui