From: Sagi Grimberg <sagi-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
To: Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH v3 25/25] IB/mlx4: Workaround for mlx4_alloc_priv_pages() array allocator
Date: Wed, 22 Jun 2016 16:29:30 +0300 [thread overview]
Message-ID: <576A92BA.3020703@grimberg.me> (raw)
In-Reply-To: <CAJ3xEMiS+arM2pYkZKSPe8zHZX_OidngCjVmPXpSjhNNf5_q2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> Ensure the MR's PBL array never occupies the last 8 bytes of a page.
>> This eliminates random "Local Protection Error" flushes when SLUB
>> debugging is enabled.
>>
>> Fixes: 1b2cd0fc673c ('IB/mlx4: Support the new memory registration API')
>
> Can't the driver advertize smaller quantity for what's occupies later
> those last eight bytes (255 or 511 of
> attr XX instead of 256 or 512)?
Not sure I understand your question. Are you suggesting that the driver
would expose that it's capable of 256 pages per MR?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Sagi Grimberg <sagi@grimberg.me>
To: Or Gerlitz <gerlitz.or@gmail.com>,
Chuck Lever <chuck.lever@oracle.com>,
Yishai Hadas <yishaih@mellanox.com>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Leon Romanovsky <leonro@mellanox.com>
Subject: Re: [PATCH v3 25/25] IB/mlx4: Workaround for mlx4_alloc_priv_pages() array allocator
Date: Wed, 22 Jun 2016 16:29:30 +0300 [thread overview]
Message-ID: <576A92BA.3020703@grimberg.me> (raw)
In-Reply-To: <CAJ3xEMiS+arM2pYkZKSPe8zHZX_OidngCjVmPXpSjhNNf5_q2A@mail.gmail.com>
>> Ensure the MR's PBL array never occupies the last 8 bytes of a page.
>> This eliminates random "Local Protection Error" flushes when SLUB
>> debugging is enabled.
>>
>> Fixes: 1b2cd0fc673c ('IB/mlx4: Support the new memory registration API')
>
> Can't the driver advertize smaller quantity for what's occupies later
> those last eight bytes (255 or 511 of
> attr XX instead of 256 or 512)?
Not sure I understand your question. Are you suggesting that the driver
would expose that it's capable of 256 pages per MR?
next prev parent reply other threads:[~2016-06-22 13:29 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 16:08 [PATCH v3 00/25] NFS/RDMA client patches proposed for v4.8 Chuck Lever
2016-06-20 16:08 ` Chuck Lever
[not found] ` <20160620155751.10809.22262.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org>
2016-06-20 16:08 ` [PATCH v3 01/25] xprtrdma: Remove FMRs from the unmap list after unmapping Chuck Lever
2016-06-20 16:08 ` Chuck Lever
[not found] ` <20160620160843.10809.96379.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org>
2016-06-27 17:47 ` Anna Schumaker
2016-06-27 17:47 ` Anna Schumaker
[not found] ` <bf577252-3786-9ee8-be3b-036922eb0507-ZwjVKphTwtPQT0dZR+AlfA@public.gmane.org>
2016-06-28 20:53 ` Chuck Lever
2016-06-28 20:53 ` Chuck Lever
2016-06-20 16:08 ` [PATCH v3 02/25] xprtrdma: Create common scatterlist fields in rpcrdma_mw Chuck Lever
2016-06-20 16:08 ` Chuck Lever
2016-06-20 16:08 ` [PATCH v3 03/25] xprtrdma: Move init and release helpers Chuck Lever
2016-06-20 16:08 ` Chuck Lever
2016-06-20 16:09 ` [PATCH v3 04/25] xprtrdma: Rename fields in rpcrdma_fmr Chuck Lever
2016-06-20 16:09 ` Chuck Lever
2016-06-20 16:09 ` [PATCH v3 05/25] xprtrdma: Use scatterlist for DMA mapping and unmapping under FMR Chuck Lever
2016-06-20 16:09 ` Chuck Lever
2016-06-20 16:09 ` [PATCH v3 06/25] xprtrdma: Refactor MR recovery work queues Chuck Lever
2016-06-20 16:09 ` Chuck Lever
2016-06-20 16:09 ` [PATCH v3 07/25] xprtrdma: Do not leak an MW during a DMA map failure Chuck Lever
2016-06-20 16:09 ` Chuck Lever
2016-06-20 16:09 ` [PATCH v3 08/25] xprtrdma: Remove ALLPHYSICAL memory registration mode Chuck Lever
2016-06-20 16:09 ` Chuck Lever
2016-06-20 16:09 ` [PATCH v3 09/25] xprtrdma: Remove rpcrdma_map_one() and friends Chuck Lever
2016-06-20 16:09 ` Chuck Lever
2016-06-20 16:09 ` [PATCH v3 10/25] xprtrdma: Clean up device capability detection Chuck Lever
2016-06-20 16:09 ` Chuck Lever
2016-06-20 16:10 ` [PATCH v3 11/25] xprtrdma: Reply buffer exhaustion can be catastrophic Chuck Lever
2016-06-20 16:10 ` Chuck Lever
2016-06-20 16:10 ` [PATCH v3 12/25] xprtrdma: Honor ->send_request API contract Chuck Lever
2016-06-20 16:10 ` Chuck Lever
2016-06-20 16:10 ` [PATCH v3 13/25] xprtrdma: Chunk list encoders must not return zero Chuck Lever
2016-06-20 16:10 ` Chuck Lever
2016-06-20 16:10 ` [PATCH v3 14/25] xprtrdma: Allocate MRs on demand Chuck Lever
2016-06-20 16:10 ` Chuck Lever
2016-06-20 16:10 ` [PATCH v3 15/25] xprtrdma: Release orphaned MRs immediately Chuck Lever
2016-06-20 16:10 ` Chuck Lever
2016-06-20 16:10 ` [PATCH v3 16/25] xprtrdma: Place registered MWs on a per-req list Chuck Lever
2016-06-20 16:10 ` Chuck Lever
2016-06-20 16:10 ` [PATCH v3 17/25] xprtrdma: Chunk list encoders no longer share one rl_segments array Chuck Lever
2016-06-20 16:10 ` Chuck Lever
2016-06-20 16:11 ` [PATCH v3 18/25] xprtrdma: rpcrdma_inline_fixup() overruns the receive page list Chuck Lever
2016-06-20 16:11 ` Chuck Lever
2016-06-20 16:11 ` [PATCH v3 19/25] xprtrdma: Do not update {head, tail}.iov_len in rpcrdma_inline_fixup() Chuck Lever
2016-06-20 16:11 ` Chuck Lever
2016-06-20 16:11 ` [PATCH v3 20/25] xprtrdma: Update only specific fields in private receive buffer Chuck Lever
2016-06-20 16:11 ` Chuck Lever
2016-06-20 16:11 ` [PATCH v3 21/25] xprtrdma: Clean up fixup_copy_count accounting Chuck Lever
2016-06-20 16:11 ` Chuck Lever
2016-06-20 16:11 ` [PATCH v3 22/25] xprtrdma: No direct data placement with krb5i and krb5p Chuck Lever
2016-06-20 16:11 ` Chuck Lever
2016-06-20 16:11 ` [PATCH v3 23/25] svc: Avoid garbage replies when pc_func() returns rpc_drop_reply Chuck Lever
2016-06-20 16:11 ` Chuck Lever
2016-06-20 16:11 ` [PATCH v3 24/25] NFS: Don't drop CB requests with invalid principals Chuck Lever
2016-06-20 16:11 ` Chuck Lever
2016-06-20 16:12 ` [PATCH v3 25/25] IB/mlx4: Workaround for mlx4_alloc_priv_pages() array allocator Chuck Lever
2016-06-20 16:12 ` Chuck Lever
[not found] ` <20160620161200.10809.45762.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org>
2016-06-21 5:52 ` Or Gerlitz
2016-06-21 5:52 ` Or Gerlitz
[not found] ` <CAJ3xEMiS+arM2pYkZKSPe8zHZX_OidngCjVmPXpSjhNNf5_q2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-22 13:29 ` Sagi Grimberg [this message]
2016-06-22 13:29 ` Sagi Grimberg
[not found] ` <576A92BA.3020703-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-06-22 13:47 ` Or Gerlitz
2016-06-22 13:47 ` Or Gerlitz
[not found] ` <CAJ3xEMiWTME0B6rKQKeCZfxK+s5p-mXcKCdThryRz+zU8V7g3g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-22 14:02 ` Sagi Grimberg
2016-06-22 14:02 ` Sagi Grimberg
2016-06-22 11:56 ` Sagi Grimberg
2016-06-22 11:56 ` Sagi Grimberg
2016-06-22 14:04 ` Sagi Grimberg
2016-06-22 14:04 ` Sagi Grimberg
[not found] ` <576A9AE6.4070500-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-06-22 14:09 ` Leon Romanovsky
2016-06-22 14:09 ` Leon Romanovsky
2016-06-22 14:47 ` Chuck Lever
2016-06-22 14:47 ` Chuck Lever
[not found] ` <A9F49204-8E84-4B58-BAA4-5B4B360FD22F-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-06-22 15:50 ` Leon Romanovsky
2016-06-22 15:50 ` Leon Romanovsky
[not found] ` <20160622155003.GI9762-2ukJVAZIZ/Y@public.gmane.org>
2016-06-22 16:20 ` Christoph Hellwig
2016-06-22 16:20 ` Christoph Hellwig
2016-06-20 18:53 ` [PATCH v3 00/25] NFS/RDMA client patches proposed for v4.8 Steve Wise
2016-06-20 18:53 ` Steve Wise
2016-06-20 19:07 ` Chuck Lever
2016-06-20 19:07 ` Chuck Lever
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=576A92BA.3020703@grimberg.me \
--to=sagi-nqwnxtmzq1alnmji0ikvqw@public.gmane.org \
--cc=chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
--cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.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.