On 3/20/2018 5:29 AM, Saeed Mahameed wrote:
On Thu, 2018-03-15 at 18:30 -0700, Matthew Wilcox wrote:
On Thu, Mar 15, 2018 at 11:58:07PM +0000, Saeed Mahameed wrote:
On Wed, 2018-03-14 at 19:57 -0700, Matthew Wilcox wrote:
From: Matthew Wilcox <mawilcox@xxxxxxxxxxxxx>
The mlx5 driver calls ida_pre_get() in a loop for no readily
apparent
reason. The driver uses ida_simple_get() which will call
ida_pre_get()
by itself and there's no need to use ida_pre_get() unless using
ida_get_new().
Hi Matthew,
Is this is causing any issues ? or just a simple cleanup ?
I'm removing the API. At the end of this cleanup, there will be no
more
preallocation; instead we will rely on the slab allocator not
sucking.
Ok, Seems reasonable, I am ok with this.
Adding Maor, the author of this change,
I believe the idea is to speed up insert_fte (which calls
ida_simple_get) since insert_fte runs under the FTE write
semaphore,
in this case if ida_pre_get was successful before taking the
semaphore
for all the FTE nodes in the loop, this will be a huge win for
ida_simple_get which will immediately return success without even
trying to allocate.
I think that's misguided. The IDA allocator is only going to
allocate
memory once in every 1024 allocations. Also, it does try to
allocate,
even if there are preallocated nodes. So you're just wasting time,
unfortunately.
Well just by looking at the code you can tell for sure that
two consecutive calls to ida_pre_get will result in one allocation
only.
due to "if (!this_cpu_read(ida_bitmap))"
but i didn't dig into details and didn't go through the whole
ida_get_new_above, so i will count on your judgment here.
Still i would like to wait for Maor's input here, the author..
I Will ping him today.
Thanks,
Saeed.
Saeed, Matan and I okay with this fix as well, it looks like it
shouldn't impact on the insertion rate.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
