From: Bob Pearson <rpearsonhpe@gmail.com>
To: Zhu Yanjun <zyjzyj2000@gmail.com>,
leon@kernel.org, linux-rdma@vger.kernel.org
Cc: Bob Pearson <rpearson@hpe.com>
Subject: Re: [PATCH for-next] rdma_rxe: address an issue with hardened user copy
Date: Wed, 26 Aug 2020 20:30:39 -0500 [thread overview]
Message-ID: <83fe1102-56f7-0632-a058-a264169789df@gmail.com> (raw)
In-Reply-To: <a63b12bf-322f-f3ef-271e-cbf12944301f@gmail.com>
On 8/26/20 8:21 PM, Zhu Yanjun wrote:
> On 8/26/2020 12:58 AM, Bob Pearson wrote:
>> Change rxe pools to use kzalloc instead of kmem_cache to allocate
>
> Why do you use kzalloc instead of kmem_cache? For performance or some bugs?
>
> Zhu Yanjun
>
>> memory for rxe objects.
>>
>> Signed-off-by: Bob Pearson <rpearson@hpe.com>
>> ---
>> drivers/infiniband/sw/rxe/rxe.c | 8 ----
>> drivers/infiniband/sw/rxe/rxe_pool.c | 60 +---------------------------
>> drivers/infiniband/sw/rxe/rxe_pool.h | 7 ----
>> 3 files changed, 2 insertions(+), 73 deletions(-)
>>
>> diff --git a/drivers/infiniband/sw/rxe/rxe.c b/drivers/infiniband/sw/rxe/rxe.c
>> index cc395da13eff..a1ff70e0b1f8 100644
>> --- a/drivers/infiniband/sw/rxe/rxe.c
>> +++ b/drivers/infiniband/sw/rxe/rxe.c
>> @@ -277,13 +277,6 @@ static int __init rxe_module_init(void)
>> {
>> int err;
>> - /* initialize slab caches for managed objects */
>> - err = rxe_cache_init();
>> - if (err) {
>> - pr_err("unable to init object pools\n");
>> - return err;
>> - }
>> -
>> err = rxe_net_init();
>> if (err)
>> return err;
>> @@ -298,7 +291,6 @@ static void __exit rxe_module_exit(void)
>> rdma_link_unregister(&rxe_link_ops);
>> ib_unregister_driver(RDMA_DRIVER_RXE);
>> rxe_net_exit();
>> - rxe_cache_exit();
>> pr_info("unloaded\n");
>> }
>> diff --git a/drivers/infiniband/sw/rxe/rxe_pool.c b/drivers/infiniband/sw/rxe/rxe_pool.c
>> index c0fab4a65f9e..70fc9f7a25b6 100644
>> --- a/drivers/infiniband/sw/rxe/rxe_pool.c
>> +++ b/drivers/infiniband/sw/rxe/rxe_pool.c
>> @@ -84,62 +84,6 @@ static inline const char *pool_name(struct rxe_pool *pool)
>> return rxe_type_info[pool->type].name;
>> }
>> -static inline struct kmem_cache *pool_cache(struct rxe_pool *pool)
>> -{
>> - return rxe_type_info[pool->type].cache;
>> -}
>> -
>> -static void rxe_cache_clean(size_t cnt)
>> -{
>> - int i;
>> - struct rxe_type_info *type;
>> -
>> - for (i = 0; i < cnt; i++) {
>> - type = &rxe_type_info[i];
>> - if (!(type->flags & RXE_POOL_NO_ALLOC)) {
>> - kmem_cache_destroy(type->cache);
>> - type->cache = NULL;
>> - }
>> - }
>> -}
>> -
>> -int rxe_cache_init(void)
>> -{
>> - int err;
>> - int i;
>> - size_t size;
>> - struct rxe_type_info *type;
>> -
>> - for (i = 0; i < RXE_NUM_TYPES; i++) {
>> - type = &rxe_type_info[i];
>> - size = ALIGN(type->size, RXE_POOL_ALIGN);
>> - if (!(type->flags & RXE_POOL_NO_ALLOC)) {
>> - type->cache =
>> - kmem_cache_create(type->name, size,
>> - RXE_POOL_ALIGN,
>> - RXE_POOL_CACHE_FLAGS, NULL);
>> - if (!type->cache) {
>> - pr_err("Unable to init kmem cache for %s\n",
>> - type->name);
>> - err = -ENOMEM;
>> - goto err1;
>> - }
>> - }
>> - }
>> -
>> - return 0;
>> -
>> -err1:
>> - rxe_cache_clean(i);
>> -
>> - return err;
>> -}
>> -
>> -void rxe_cache_exit(void)
>> -{
>> - rxe_cache_clean(RXE_NUM_TYPES);
>> -}
>> -
>> static int rxe_pool_init_index(struct rxe_pool *pool, u32 max, u32 min)
>> {
>> int err = 0;
>> @@ -381,7 +325,7 @@ void *rxe_alloc(struct rxe_pool *pool)
>> if (atomic_inc_return(&pool->num_elem) > pool->max_elem)
>> goto out_cnt;
>> - elem = kmem_cache_zalloc(pool_cache(pool),
>> + elem = kzalloc(rxe_type_info[pool->type].size,
>> (pool->flags & RXE_POOL_ATOMIC) ?
>> GFP_ATOMIC : GFP_KERNEL);
>> if (!elem)
>> @@ -443,7 +387,7 @@ void rxe_elem_release(struct kref *kref)
>> pool->cleanup(elem);
>> if (!(pool->flags & RXE_POOL_NO_ALLOC))
>> - kmem_cache_free(pool_cache(pool), elem);
>> + kfree(elem);
>> atomic_dec(&pool->num_elem);
>> ib_device_put(&pool->rxe->ib_dev);
>> rxe_pool_put(pool);
>> diff --git a/drivers/infiniband/sw/rxe/rxe_pool.h b/drivers/infiniband/sw/rxe/rxe_pool.h
>> index 64d92be3f060..3d722aae5f15 100644
>> --- a/drivers/infiniband/sw/rxe/rxe_pool.h
>> +++ b/drivers/infiniband/sw/rxe/rxe_pool.h
>> @@ -42,7 +42,6 @@ struct rxe_type_info {
>> u32 min_index;
>> size_t key_offset;
>> size_t key_size;
>> - struct kmem_cache *cache;
>> };
>> extern struct rxe_type_info rxe_type_info[];
>> @@ -96,12 +95,6 @@ struct rxe_pool {
>> } key;
>> };
>> -/* initialize slab caches for managed objects */
>> -int rxe_cache_init(void);
>> -
>> -/* cleanup slab caches for managed objects */
>> -void rxe_cache_exit(void);
>> -
>> /* initialize a pool of objects with given limit on
>> * number of elements. gets parameters from rxe_type_info
>> * pool elements will be allocated out of a slab cache
>
>
There is a regression in rxe caused by the hardened usercopy patches. It leads to a kernel warning the first time a QP is created each boot. The origin has been discussed in several emails between Leon myself and the list. There are a lot of ways to eliminate the warning but so far there has been resistance to any of these fixes. As far as I can tell there is no performance hit from moving from kmem_cache to kzalloc. (kzalloc and kmalloc just use pre defined caches with objects that are powers of 2 in size.) I am waiting for Leon to express an opinion on this solution. He also has a proposal to allocate QP objects in the core (like PD, etc).
Bob
next prev parent reply other threads:[~2020-08-27 1:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-25 16:58 [PATCH for-next] rdma_rxe: address an issue with hardened user copy Bob Pearson
2020-08-27 1:21 ` Zhu Yanjun
2020-08-27 1:30 ` Bob Pearson [this message]
2020-08-27 7:02 ` Leon Romanovsky
2020-08-27 13:58 ` Jason Gunthorpe
2020-08-27 16:43 ` Bob Pearson
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=83fe1102-56f7-0632-a058-a264169789df@gmail.com \
--to=rpearsonhpe@gmail.com \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=rpearson@hpe.com \
--cc=zyjzyj2000@gmail.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