On Mon, Sep 25, 2017 at 11:49:49AM -0300, Arnaldo Carvalho de Melo wrote:
> Hi,
>
> I'm trying to get an Infiniband test case working with the RT
> kernel, and ended over tripping over this case:
>
> In drivers/infiniband/hw/hfi1/pio.c sc_buffer_alloc() disables
> preemption that will be reenabled by either pio_copy() or
> seg_pio_copy_end().
Perhaps it's worth revisiting why this design decision was chosen in the
first place? The introducing commit, a054374f15428cbc1
("staging/rdma/hfi1: convert buffers allocated atomic to per cpu")
mentions the previous atomic as being expensive, but the usage of
preempt_disable()/preempt_enable() is also expensive, albeit in a
different way.
My first question would be: is disabling preemption here really
necessary?
AFAICT, preemption is only disabled to protect the access of the
'buffers_allocated' percpu counters, nothing else.
However, because these counters are only observed in aggregate, across
CPUs (see get_buffers_allocated()), the sum will be the same, regardless
of a thread is migrated between a this_cpu_inc(buffers_allocated) and a
this_cpu_dec(buffers_allocated).
If that's the case, perhaps the fix is as easy as removing the
preempt_disable() and preempt_enable()?
Julia
PS. Perhaps a longer term approach would be to investigate whether the
usage of percpu_ref or percpu_counter is a better fit for this driver.
--
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
