On 4/16/2014 6:08 PM, Chuck Lever wrote:
Hi Sagi- Thanks for the review! In-line replies below.
<SNIP>
2. If I understood correctly, I see that the CQs are loop-polled in an interrupt context. This may become problematic in stress workload where the CQ simply never drains (imagine some studios task keeps posting WRs as soon as IOs complete). This will cause CQ poll loop to go on forever. This situation may cause starvation of other CQs that share the same EQ (CPU is hogged by the endless poller). This may be solved in 2 ways: - Use blk-iopoll to maintain fairness - the downside will be moving from interrupt context to soft-irq (slower). - Set some configurable budget to CQ poller - after finishing the budget, notify the CQ and bail. If there is another CQ waiting to get in - it's only fair that it will be given with a chance, else another interrupt on that CQ will immediately come.I think it would be a reasonable change to pass an array of WC’s to ib_poll_cq() just once in rpcrdma_{send,recv}cq_poll(), instead of looping. Would that be enough? To be clear, my patch merely cleans up the completion handler logic, which already did loop-polling. Should we consider this improvement for another patch?
Well, I wasn't suggesting passing an array, carrying it around (or on the stack for that manner) might be annoying... I was suggesting a budget (poll loops or a time bound - jiffy is usually well behaved).
Sagi. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
