From: Jason Gunthorpe <jgg@mellanox.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Doug Ledford <dledford@redhat.com>,
RDMA mailing list <linux-rdma@vger.kernel.org>,
Erez Alfasi <ereza@mellanox.com>
Subject: Re: [PATCH rdma-next v2 1/4] IB/mlx5: Introduce ODP diagnostic counters
Date: Thu, 10 Oct 2019 19:49:40 +0000 [thread overview]
Message-ID: <20191010194936.GI11569@mellanox.com> (raw)
In-Reply-To: <20191010090203.GJ5855@unreal>
On Thu, Oct 10, 2019 at 12:02:03PM +0300, Leon Romanovsky wrote:
> > > static inline bool is_odp_mr(struct mlx5_ib_mr *mr)
> > > diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c
> > > index 95cf0249b015..966783bfb557 100644
> > > +++ b/drivers/infiniband/hw/mlx5/odp.c
> > > @@ -261,6 +261,10 @@ void mlx5_ib_invalidate_range(struct ib_umem_odp *umem_odp, unsigned long start,
> > > blk_start_idx = idx;
> > > in_block = 1;
> > > }
> > > +
> > > + /* Count page invalidations */
> > > + mlx5_update_odp_stats(mr, invalidations,
> > > + (idx - blk_start_idx + 1));
> >
> > I feel like these should be batched and the atomic done once at the
> > end of the routine..
>
> We can, but does it worth it?
Probably since it is so simple, atomics are very expensive
> For various reasons we are delaying this series for months already.
> Let's drop "prefetch" counter for now and merge everything without
> it.
OK, I guess the counters are extendible as we go along, however see below:
> > This is also not quite right for prefetch as we are doing a form of
> > prefetching in the mlx5_ib_mr_rdma_pfault_handler() too, although it
> > is less clear how to count those. Maybe this should be split to SQ/RQ
> > faults?
>
> mlx5_ib_mr_rdma_pfault_handler() calls to pagefault_single_data_segment()
> without MLX5_PF_FLAGS_PREFETCH, so I'm unsure that this counter should
> count mlx5_ib_mr_rdma_pfault_handler() pagefaults.
>
> However the idea to separate SQ/RQ for everything sounds appealing.
Let's at least have a well defined counter design. SQ/RQ seems like a
good split to me as they have quite different behavior on mlx5
hardware, so splitting the existing counter seems good anyhow
Jason
next prev parent reply other threads:[~2019-10-10 19:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-06 15:51 [PATCH rdma-next v2 0/4] ODP information and statistics Leon Romanovsky
2019-10-06 15:51 ` [PATCH rdma-next v2 1/4] IB/mlx5: Introduce ODP diagnostic counters Leon Romanovsky
2019-10-08 19:57 ` Jason Gunthorpe
2019-10-10 9:02 ` Leon Romanovsky
2019-10-10 19:49 ` Jason Gunthorpe [this message]
2019-10-06 15:51 ` [PATCH rdma-next v2 2/4] RDMA/nldev: Allow different fill function per resource Leon Romanovsky
2019-10-08 19:58 ` Jason Gunthorpe
2019-10-06 15:51 ` [PATCH rdma-next v2 3/4] RDMA/mlx5: Return ODP type per MR Leon Romanovsky
2019-10-06 15:51 ` [PATCH rdma-next v2 4/4] RDMA/nldev: Provide MR statistics Leon Romanovsky
2019-10-09 14:40 ` Jason Gunthorpe
2019-10-10 9:02 ` 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=20191010194936.GI11569@mellanox.com \
--to=jgg@mellanox.com \
--cc=dledford@redhat.com \
--cc=ereza@mellanox.com \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
/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.