On 12/23/2015 03:01 PM, ira.weiny wrote: > Doug, > > With your email troubles I just wanted to make sure you did not lose track of > this patch. > > https://patchwork.kernel.org/patch/7822511/
I've got it, thanks. > Thanks, > Ira > > On Thu, Dec 10, 2015 at 04:52:30PM -0500, [email protected] wrote: >> From: Dean Luick <[email protected]> >> >> It was found that when a process was rapidly sending MADs other processes >> could >> be hung in their unregister calls. >> >> This would happen when process A was injecting packets fast enough that the >> single threaded workqueue was never exiting ib_mad_completion_handler. >> Therefore when process B called flush_workqueue via the unregister call it >> would hang until process A stopped sending MADs. >> >> The fix is to periodically reschedule ib_mad_completion_handler after >> processing a large number of completions. The number of completions chosen >> was >> decided based on the defaults for the recv queue size. However, it was kept >> fixed such that increasing those queue sizes would not adversely affect >> fairness in the future. >> >> Reviewed-by: Ira Weiny <[email protected]> >> Signed-off-by: Dean Luick <[email protected]> >> --- >> drivers/infiniband/core/mad.c | 18 ++++++++++++++++++ >> 1 file changed, 18 insertions(+) >> >> diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c >> index 2281de122038..d4d2a618fd66 100644 >> --- a/drivers/infiniband/core/mad.c >> +++ b/drivers/infiniband/core/mad.c >> @@ -61,6 +61,18 @@ MODULE_PARM_DESC(send_queue_size, "Size of send queue in >> number of work requests >> module_param_named(recv_queue_size, mad_recvq_size, int, 0444); >> MODULE_PARM_DESC(recv_queue_size, "Size of receive queue in number of work >> requests"); >> >> +/* >> + * Define a limit on the number of completions which will be processed by >> the >> + * worker thread in a single work item. This ensures that other work items >> + * (potentially from other users) are processed fairly. >> + * >> + * The number of completions was derived from the default queue sizes above. >> + * We use a value which is double the larger of the 2 queues (receive @ 512) >> + * but keep it fixed such that an increase in that value does not introduce >> + * unfairness. >> + */ >> +#define MAD_COMPLETION_PROC_LIMIT 1024 >> + >> static struct list_head ib_mad_port_list; >> static u32 ib_mad_client_id = 0; >> >> @@ -2555,6 +2567,7 @@ static void ib_mad_completion_handler(struct >> work_struct *work) >> { >> struct ib_mad_port_private *port_priv; >> struct ib_wc wc; >> + int count = 0; >> >> port_priv = container_of(work, struct ib_mad_port_private, work); >> ib_req_notify_cq(port_priv->cq, IB_CQ_NEXT_COMP); >> @@ -2574,6 +2587,11 @@ static void ib_mad_completion_handler(struct >> work_struct *work) >> } >> } else >> mad_error_handler(port_priv, &wc); >> + >> + if (++count > MAD_COMPLETION_PROC_LIMIT) { >> + queue_work(port_priv->wq, &port_priv->work); >> + break; >> + } >> } >> } >> >> -- >> 1.8.2 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in >> the body of a message to [email protected] >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Doug Ledford <[email protected]> GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
