[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aUGYjfE7mlSUfL_3@x1.local>
Date: Tue, 16 Dec 2025 12:36:13 -0500
From: Peter Xu <peterx@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: kvm@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Nico Pache <npache@...hat.com>, Zi Yan <ziy@...dia.com>,
Alex Mastro <amastro@...com>, David Hildenbrand <david@...hat.com>,
Alex Williamson <alex@...zbot.org>, Zhi Wang <zhiw@...dia.com>,
David Laight <david.laight.linux@...il.com>,
Yi Liu <yi.l.liu@...el.com>, Ankit Agrawal <ankita@...dia.com>,
Kevin Tian <kevin.tian@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 2/4] mm: Add file_operations.get_mapping_order()
On Tue, Dec 16, 2025 at 01:19:44PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 16, 2025 at 10:42:39AM -0500, Peter Xu wrote:
> > Also see __thp_get_unmapped_area() processed such pgoff, it allocates VA
> > with len_pad (not len), and pad the retval at last.
> >
> > Please let me know if it didn't work like it, then it might be a bug.
>
> It should all be documented then in the kdoc for the new ops, in this
> kind of language that the resulting VA flows from pgoff
IMHO that's one of the major benefits of this API, so that there's no need
to mention impl details like this.
I thought that's also what you wanted as well.. as you're further
suggesting to offload order adjustments to core mm, which I tend to agree.
Here the point is, the driver should only care about the size of mapping,
nothing else like how exactly the alignments will be calculated, and how
that interacts with pgoff. The kernel mm manages that. It's done exactly
like what anon thp does already when len is pmd aligned.
Or maybe I misunderstood what you're suggesting to document? If so, please
let me know; some example would be greatly helpful.
Thanks,
--
Peter Xu
Powered by blists - more mailing lists