From: Jason Gunthorpe <jgg@nvidia.com>
To: Steven Sistare <steven.sistare@oracle.com>
Cc: iommu@lists.linux.dev, Kevin Tian <kevin.tian@intel.com>,
Nicolin Chen <nicolinc@nvidia.com>
Subject: Re: [PATCH V3 8/9] iommufd: optimize file mapping
Date: Fri, 18 Oct 2024 20:10:11 -0300 [thread overview]
Message-ID: <20241018231011.GL3559746@nvidia.com> (raw)
In-Reply-To: <55027ff1-05cb-4ce9-adad-8dca586a26ac@oracle.com>
On Fri, Oct 18, 2024 at 02:10:26PM -0400, Steven Sistare wrote:
> > > > But why is that such a problem? The ufolios_offset already handles a
> > > > partial folio.
> > > >
> > > > If the batch fills you leave ufolios_next alone and adjust
> > > > ufolios_offset. The next iteration does exactly the same as the first
> > > > iteration and takes the partial folio.
> > > >
> > > > The refcount has to be handled carefully as the the portion that has
> > > > been put in the batch needs to be refcounted at 4k and the remainder
> > > > remain a single ref, but that just means adjusting the refcount after
> > > > putting it in the batch.
> > > >
> > > > It seems like it just works naturally and avoids the double loop
> > >
> > > Yes, I can squash the nested loop in batch_from_folios_huge. (I was off
> > > point because I thought you were suggesting something else).
> > >
> > > Do you want me to delete ufolios_huge and its special cases?
> >
> > I think yes, if you can get to one loop then it would be a degradation
> > to sweep the folio list an extra time just to figure out ufolios_huge.
>
> So now I'm confused again and don't know which "double loops" you want me
> to eliminate. There is still a loop in pin_memfd_pages. It calls folio_add_pins,
> which I could push to batch_from_folios_huge, but it also counts and returns
> pages.
This is the one I was looking at, yes..
> It must do the count because the caller calls
> iopt_pages_add_npinned().
Ah, this is what I was trying to get to, if there was some reason why
this loop and this pages calculation was needed..
So, to fix that up you'd need to adjust the memfd_pin_folios() to also
return back the end va of what it returned - it calls it start_idx
internally. Then that can directly give the npages for add_npinned
with simple math and the loop in pin_memfd_pages can go away.
Then you have a single loop in the batch_from_folios(), which
is what I am thinking about.
What do you think?
Jason
next prev parent reply other threads:[~2024-10-18 23:10 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-04 18:48 [PATCH V3 0/9] iommu_ioas_map_file Steve Sistare
2024-10-04 18:48 ` [PATCH V3 1/9] mm/gup: folio_add_pins Steve Sistare
2024-10-04 18:52 ` Steven Sistare
2024-10-04 20:20 ` David Hildenbrand
2024-10-16 12:17 ` Jason Gunthorpe
2024-10-04 18:48 ` [PATCH V3 2/9] iommufd: rename uptr in iopt_alloc_iova Steve Sistare
2024-10-04 18:48 ` [PATCH V3 3/9] iommufd: generalize iopt_pages address Steve Sistare
2024-10-04 18:48 ` [PATCH V3 4/9] iommufd: pfn reader for file mappings Steve Sistare
2024-10-16 12:37 ` Jason Gunthorpe
2024-10-17 17:01 ` Steven Sistare
2024-10-17 19:20 ` Jason Gunthorpe
2024-10-04 18:48 ` [PATCH V3 5/9] iommufd: IOMMU_IOAS_MAP_FILE Steve Sistare
2024-10-16 12:41 ` Jason Gunthorpe
2024-10-17 17:00 ` Steven Sistare
2024-10-17 19:20 ` Jason Gunthorpe
2024-10-04 18:48 ` [PATCH V3 6/9] iommufd: file mappings for mdev Steve Sistare
2024-10-04 18:48 ` [PATCH V3 7/9] iommufd: pfn reader local variables Steve Sistare
2024-10-16 12:42 ` Jason Gunthorpe
2024-10-04 18:48 ` [PATCH V3 8/9] iommufd: optimize file mapping Steve Sistare
2024-10-16 13:00 ` Jason Gunthorpe
2024-10-16 13:09 ` Steven Sistare
2024-10-16 13:21 ` Jason Gunthorpe
2024-10-17 17:02 ` Steven Sistare
2024-10-17 19:24 ` Jason Gunthorpe
2024-10-17 19:37 ` Steven Sistare
2024-10-18 0:10 ` Jason Gunthorpe
2024-10-18 14:34 ` Steven Sistare
2024-10-18 16:04 ` Jason Gunthorpe
2024-10-18 17:54 ` Steven Sistare
2024-10-18 17:59 ` Jason Gunthorpe
2024-10-18 18:10 ` Steven Sistare
2024-10-18 23:10 ` Jason Gunthorpe [this message]
2024-10-21 14:06 ` Steven Sistare
2024-10-21 14:29 ` Steven Sistare
2024-10-21 16:11 ` Jason Gunthorpe
2024-10-21 17:29 ` Steven Sistare
2024-10-21 16:10 ` Jason Gunthorpe
2024-10-04 18:48 ` [PATCH V3 9/9] iommufd: map file selftest Steve Sistare
2024-10-16 12:23 ` [PATCH V3 0/9] iommu_ioas_map_file Jason Gunthorpe
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=20241018231011.GL3559746@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=kevin.tian@intel.com \
--cc=nicolinc@nvidia.com \
--cc=steven.sistare@oracle.com \
/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.