On 10/30/2014 5:19 PM, Bart Van Assche wrote:
On 10/30/14 16:06, Sagi Grimberg wrote:
I'm not aware of any implicit interrupt coalescing effect...
In case it was not clear what I was referring to: if multiple completion
queue handling routines run on the same CPU then the average number of
work completions processed by each completion handling routine increases
due to the increased time between generation of an interrupt and the
start of the completion handler routine. As you know this helps overall
system throughput.
Now I realize that we can hit serious problems here since we never
solved the issue of srp polling routine that might poll forever within
an interrupt (or at least until a hard lockup). Its interesting that
you weren't able to hit that with a high workload. Did you try running
this code on a virtual function (I witnessed this issue in iser on a VM).
Moreover, the fairness issue is even more likely to be encountered in
multichannel. Did you try to hit that? I really think this patchset
*needs* to deal with the 2 issues I mentioned as the probability of
hitting them increases with a faster IO stack.
I remember this was discussed lately with consideration for using
blk-iopoll or not. But I think that for now the initial approach of
bailing out of the once we hit a budget is fine for now.
Sagi.
--
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
