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-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
