summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/call-graph-from-sql.py
diff options
context:
space:
mode:
authorJulian Wiedmann <jwi@linux.vnet.ibm.com>2018-04-19 12:52:07 +0200
committerDavid S. Miller <davem@davemloft.net>2018-04-22 14:42:31 -0400
commit901e3f49facbd31b2b3d1786637b4a35e1022e9b (patch)
tree58b003cebb779adf39593748b9b478d2318e1d4d /tools/perf/scripts/python/call-graph-from-sql.py
parent686c97ee29c886ee07d17987d0059874c5c3b5af (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