summaryrefslogtreecommitdiff
path: root/drivers/video
diff options
context:
space:
mode:
authorHerbert Xu <herbert@gondor.apana.org.au>2010-01-25 23:51:01 (GMT)
committerDavid S. Miller <davem@davemloft.net>2010-01-25 23:51:01 (GMT)
commit39d321577405e8e269fd238b278aaf2425fa788a (patch)
tree923bded413373b0ee72b0929fa7413953888da12 /drivers/video
parent5a27e86babe79cf5f575394bb1055448458df6c7 (diff)
downloadlinux-fsl-qoriq-39d321577405e8e269fd238b278aaf2425fa788a.tar.xz
virtio_net: Make delayed refill more reliable
I have seen RX stalls on a machine that experienced a suspected OOM. After the stall, the RX buffer is empty on the guest side and there are exactly 16 entries available on the host side. As the number of entries is less than that required by a maximal skb, the host cannot proceed. The guest did not have a refill job scheduled. My diagnosis is that an OOM had occured, with the delayed refill job scheduled. The job was able to allocate at least one skb, but not enough to overcome the minimum required by the host to proceed. As the refill job would only reschedule itself if it failed completely to allocate any skbs, this would lead to an RX stall. The following patch removes this stall possibility by always rescheduling the refill job until the ring is totally refilled. Testing has shown that the RX stall no longer occurs whereas previously it would occur within a day. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/video')
0 files changed, 0 insertions, 0 deletions