diff options
author | Julian Wiedmann <jwi@linux.vnet.ibm.com> | 2018-04-19 12:52:07 +0200 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2018-04-22 14:42:31 -0400 |
commit | 901e3f49facbd31b2b3d1786637b4a35e1022e9b (patch) | |
tree | 58b003cebb779adf39593748b9b478d2318e1d4d /tools/perf/scripts/python/call-graph-from-sql.py | |
parent | 686c97ee29c886ee07d17987d0059874c5c3b5af (diff) |
s390/qeth: avoid control IO completion stalls
For control IO, qeth currently tracks the index of the buffer that it
expects to complete the next IO on each qeth_channel. If the channel
presents an IRQ while this buffer has not yet completed, no completion
processing for _any_ completed buffer takes place.
So if the 'next buffer' is skipped for any sort of reason* (eg. when it
is released due to error conditions, before the IO is started), the
buffer obviously won't switch to PROCESSED until it is eventually
allocated for a _different_ IO and completes.
Until this happens, all completion processing on that channel stalls
and pending requests possibly time out.
As a fix, remove the whole 'next buffer' logic and simply process any
IO buffer right when it completes. A channel will never have more than
one IO pending, so there's no risk of processing out-of-sequence.
*Note: currently just one location in the code really handles this problem,
by advancing the 'next' index manually.
Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'tools/perf/scripts/python/call-graph-from-sql.py')
0 files changed, 0 insertions, 0 deletions