Linux IOMMU Development
 help / color / mirror / Atom feed
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 V2 8/9] iommufd: optimize file mapping
Date: Wed, 2 Oct 2024 14:29:04 -0300	[thread overview]
Message-ID: <20241002172904.GT1365916@nvidia.com> (raw)
In-Reply-To: <a8005da1-6f89-4934-a010-73867b596239@oracle.com>

On Wed, Oct 02, 2024 at 01:26:32PM -0400, Steven Sistare wrote:
> On 10/1/2024 5:03 PM, Jason Gunthorpe wrote:
> > On Tue, Sep 24, 2024 at 08:05:37AM -0700, Steve Sistare wrote:
> > > @@ -622,6 +630,67 @@ static void batch_from_pages(struct pfn_batch *batch, struct page **pages,
> > >   			break;
> > >   }
> > > +static void batch_from_folios(struct pfn_batch *batch, struct folio **folios,
> > > +			      unsigned long offset, unsigned long npages)
> > > +{
> > > +	unsigned long nr, pfn, i = 0;
> > > +	struct folio *folio;
> > > +
> > > +	while (npages) {
> > > +		folio = folios[i++];
> > > +		nr = folio_nr_pages(folio) - offset;
> > > +		nr = min_t(unsigned long, nr, npages);
> > > +		pfn = page_to_pfn(folio_page(folio, offset));
> > > +		batch_add_pfn_num(batch, pfn, nr);
> > 
> > I think we technically need to cap nr here as well?
> 
> Do you mean cap nr at max-unsigned-int and loop over the folio?

The max that can be put into a batch entry

> > Why does this exist? I would expect you'd call memfd_pin_folios with
> > the correct offset so that the first folio was the right folio, this
> > is how the pin_user_pages path works?
> 
> We need folios_start for the case where the 'if' branch below is not taken,
> so the folio was pinned by a previous call to pfn_reader_fill_span,
> so the requested start_index for the current call does not necessarily
> fall in the first folio of user->ufolios.

But that should be handled by keeping track of where we are in the
array, not searching it again..


> > > +static void folios_unpin_partial(struct folio **folios, unsigned long offset,
> > > +				 unsigned long npages)
> > > +{
> > > +	unsigned long nr, j, i = 0;
> > > +	struct folio *folio;
> > > +
> > > +	while (npages) {
> > > +		folio = folios[i++];
> > > +		nr = folio_nr_pages(folio);
> > > +		if (offset == 0 && nr < npages) {
> > > +			unpin_folio(folio);
> > > +		} else {
> > > +			nr = min_t(unsigned long, npages, nr - offset);
> > > +			for (j = 0; j < nr; j++)
> > > +				unpin_user_page(folio_page(folio, offset + j));
> > 
> > Don't loop, we have unpin_user_pages() for this
> 
> Cannot call it, I do not have a pages[] array in hand.

Ugh, still, don't loop, this needs a new mm helper then

Jason

  reply	other threads:[~2024-10-02 17:29 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-24 15:05 [PATCH V2 0/9] iommu_ioas_map_file Steve Sistare
2024-09-24 15:05 ` [PATCH V2 1/9] iommufd: rename uptr in iopt_alloc_iova Steve Sistare
2024-09-27 15:59   ` Jason Gunthorpe
2024-09-24 15:05 ` [PATCH V2 2/9] iommufd: generalize iopt_pages address Steve Sistare
2024-09-24 20:31   ` Nicolin Chen
2024-09-25 22:43     ` Jason Gunthorpe
2024-09-25 23:04       ` Nicolin Chen
2024-09-26 14:48         ` Jason Gunthorpe
2024-09-26 15:48           ` Steven Sistare
2024-10-01 19:54   ` Jason Gunthorpe
2024-09-24 15:05 ` [PATCH V2 3/9] iommufd: pfn reader for file mappings Steve Sistare
2024-09-24 20:53   ` Nicolin Chen
2024-09-26 15:59     ` Steven Sistare
2024-09-25  1:32   ` kernel test robot
2024-09-25  1:55   ` kernel test robot
2024-09-26 14:10   ` Steven Sistare
2024-09-24 15:05 ` [PATCH V2 4/9] iommufd: IOMMU_IOAS_MAP_FILE interface Steve Sistare
2024-10-01 19:58   ` Jason Gunthorpe
2024-09-24 15:05 ` [PATCH V2 5/9] iommufd: IOMMU_IOAS_MAP_FILE implementation Steve Sistare
2024-09-24 21:08   ` Nicolin Chen
2024-09-26 15:50     ` Steven Sistare
2024-10-01 20:05   ` Jason Gunthorpe
2024-10-02 17:26     ` Steven Sistare
2024-09-24 15:05 ` [PATCH V2 6/9] iommufd: file mappings for mdev Steve Sistare
2024-10-01 20:09   ` Jason Gunthorpe
2024-10-02 17:26     ` Steven Sistare
2024-09-24 15:05 ` [PATCH V2 7/9] iommufd: pfn reader local variables Steve Sistare
2024-10-02 17:29   ` Steven Sistare
2024-10-04 12:16     ` Jason Gunthorpe
2024-09-24 15:05 ` [PATCH V2 8/9] iommufd: optimize file mapping Steve Sistare
2024-10-01 21:03   ` Jason Gunthorpe
2024-10-02 17:26     ` Steven Sistare
2024-10-02 17:29       ` Jason Gunthorpe [this message]
2024-10-02 17:51         ` Steven Sistare
2024-09-24 15:05 ` [PATCH V2 9/9] iommufd: map file selftest Steve Sistare
2024-10-01 21:05   ` Jason Gunthorpe
2024-10-02 17:26     ` Steven Sistare
2024-10-02 17:29       ` 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=20241002172904.GT1365916@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox