From: Peter Xu <peterx@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Jay Zhou <jianjay.zhou@huawei.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
cohuck@redhat.com, maoming.maoming@huawei.com,
weidong.huang@huawei.com, Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [PATCH] vfio dma_map/unmap: optimized for hugetlbfs pages
Date: Tue, 21 Jul 2020 20:48:51 -0400 [thread overview]
Message-ID: <20200722004851.GV535743@xz-x1> (raw)
In-Reply-To: <20200720164603.3a622548@x1.home>
On Mon, Jul 20, 2020 at 04:46:03PM -0600, Alex Williamson wrote:
> > + /*
> > + * We got a hugetlbfs page using vaddr_get_pfn alreadly.
> > + * In this case,we do not need to alloc pages and we can finish all
> > + * work by a single operation to the head page.
> > + */
> > + lock_acct += contiguous_npage;
> > + head = compound_head(pfn_to_page(*pfn_base));
> > + atomic_add(contiguous_npage, compound_pincount_ptr(head));
> > + page_ref_add(head, contiguous_npage);
> > + mod_node_page_state(page_pgdat(head), NR_FOLL_PIN_ACQUIRED, contiguous_npage);
> > + pinned += contiguous_npage;
> > + goto out;
>
> I'm hoping Peter or Andrea understand this, but I think we still have
> pfn_base pinned separately and I don't see that we've done an unpin
> anywhere, so are we leaking the pin of the first page??
I'm not very familiar with that either, however it seems to me most of above
chunk was already done in the gup core. For hugetlbfs, imho it should be where
follow_hugetlb_page() calls try_grab_page(). Thanks,
--
Peter Xu
prev parent reply other threads:[~2020-07-22 0:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-20 8:29 [PATCH] vfio dma_map/unmap: optimized for hugetlbfs pages Jay Zhou
2020-07-20 14:24 ` kernel test robot
2020-07-20 22:46 ` Alex Williamson
2020-07-21 13:28 ` Zhoujian (jay)
2020-08-13 6:11 ` 答复: " Maoming (maoming, Cloud Infrastructure Service Product Dept.)
2020-07-22 0:48 ` Peter Xu [this message]
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=20200722004851.GV535743@xz-x1 \
--to=peterx@redhat.com \
--cc=aarcange@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=jianjay.zhou@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maoming.maoming@huawei.com \
--cc=weidong.huang@huawei.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