All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Yishai Hadas <yishaih@nvidia.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	Doug Ledford <dledford@redhat.com>, <linux-rdma@vger.kernel.org>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH rdma-next v2 1/4] IB/core: Improve ODP to use hmm_range_fault()
Date: Tue, 29 Sep 2020 21:35:31 -0300	[thread overview]
Message-ID: <20200930003531.GA816047@nvidia.com> (raw)
In-Reply-To: <c3b37733-f48b-bc97-9077-60dab5954702@nvidia.com>

On Wed, Sep 30, 2020 at 12:34:55AM +0300, Yishai Hadas wrote:
> On 9/29/2020 11:13 PM, Jason Gunthorpe wrote:
> > > > > +		WARN_ON(!(range.hmm_pfns[pfn_index] & HMM_PFN_VALID));
> > > > > +		hmm_order = hmm_pfn_to_map_order(range.hmm_pfns[pfn_index]);
> > > > > +		/* If a hugepage was detected and ODP wasn't set for, the umem
> > > > > +		 * page_shift will be used, the opposite case is an error.
> > > > > +		 */
> > > > > +		if (hmm_order + PAGE_SHIFT < page_shift) {
> > > > > +			ret = -EINVAL;
> > > > > +			pr_debug("%s: un-expected hmm_order %d, page_shift %d\n",
> > > > > +				 __func__, hmm_order, page_shift);
> > > > >    			break;
> > > > >    		}
> > > > I think this break should be a continue here. There is no reason not
> > > > to go to the next aligned PFN and try to sync as much as possible.
> > > This might happen if the application didn't honor the contract to use
> > > hugepages for the full range despite that it sets IB_ACCESS_HUGETLB, right ?
> > Yes
> > 
> > > Do we still need to sync as much as possible in that case ? I
> > > believe that we may consider return an error in this case to let
> > > application be aware of as was before this series.
> > We might be prefetching or something weird where it could make sense.
> > 
> 
> In addition to my previous note here as of below [1], ignoring the clear
> error case might break some testing that expects to get an error in this
> case when the contract was not honored.

The error code should be preserved, but not all callers care, like
prefetch for instance

> Also not sure how the HW will behave, won't that cause an extra / infinite
> call to the driver to page fault for the missing data as the result will be
> success but no dma will be provided ?
> As of that I believe that better leave the code as is, what do you think ?

The HW must trigger fail if it reaches a pfn that isn't valid. The
return code is an indirect indication this happened.

Please send an update tomorre with these small changes since it is
late for me now

Jason

  reply	other threads:[~2020-09-30  0:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  8:21 [PATCH rdma-next v2 0/4] Improve ODP by using HMM API Leon Romanovsky
2020-09-22  8:21 ` [PATCH rdma-next v2 1/4] IB/core: Improve ODP to use hmm_range_fault() Leon Romanovsky
2020-09-29 17:59   ` Jason Gunthorpe
2020-09-29 18:02     ` Christoph Hellwig
2020-09-29 18:13       ` Jason Gunthorpe
2020-09-29 18:15         ` Christoph Hellwig
2020-09-29 18:27           ` Jason Gunthorpe
2020-09-29 20:20     ` Yishai Hadas
2020-09-29 19:27   ` Jason Gunthorpe
2020-09-29 20:09     ` Yishai Hadas
2020-09-29 20:13       ` Jason Gunthorpe
2020-09-29 20:30         ` Yishai Hadas
2020-09-30  0:37           ` Jason Gunthorpe
2020-09-29 21:34         ` Yishai Hadas
2020-09-30  0:35           ` Jason Gunthorpe [this message]
2020-09-30  7:32             ` Yishai Hadas
2020-09-22  8:21 ` [PATCH rdma-next v2 2/4] IB/core: Enable ODP sync without faulting Leon Romanovsky
2020-09-22  8:21 ` [PATCH rdma-next v2 3/4] RDMA/mlx5: Extend advice MR to support non faulting mode Leon Romanovsky
2020-09-22  8:21 ` [PATCH rdma-next v2 4/4] RDMA/mlx5: Sync device with CPU pages upon ODP MR registration Leon Romanovsky

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=20200930003531.GA816047@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=dledford@redhat.com \
    --cc=hch@infradead.org \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=yishaih@nvidia.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.