59adbba20f
Fix a problem where the blockback driver could run out of requests, despite the fact that we allocate enough request and reqlist structures to satisfy the maximum possible number of requests. The problem was that we were sending responses back to the other end (blockfront) before freeing resources. The Citrix Windows driver is pretty agressive about queueing, and would queue more I/O to us immediately after we sent responses to it. We would run into a resource shortage and stall out I/O until we freed resources. It isn't clear whether the request shortage condition was an indirect cause of the I/O hangs we've been seeing between Windows with the Citrix PV drivers and FreeBSD's blockback, but the above problem is certainly a bug. Sponsored by: Spectra Logic Submitted by: ken Reviewed by: royger dev/xen/blkback/blkback.c: - Break xbb_send_response() into two sub-functions, xbb_queue_response() and xbb_push_responses(). Remove xbb_send_response(), because it is no longer used. - Adjust xbb_complete_reqlist() so that it calls the two new functions, and holds the mutex around both calls. The mutex insures that another context can't come along and push responses before we've freed our resources. - Change xbb_release_reqlist() so that it requires the mutex to be held instead of acquiring the mutex itself. Both callers could easily hold the mutex while calling it, and one really needs to hold the mutex during the call. - Add two new counters, accessible via sysctl variables. The first one counts the number of I/Os that are queued and waiting to be pushed (reqs_queued_for_completion). The second one (reqs_completed_with_error) counts the number of requests we've completed with an error status. |
||
|---|---|---|
| .. | ||
| balloon | ||
| blkback | ||
| blkfront | ||
| console | ||
| control | ||
| netback | ||
| netfront | ||
| pcifront | ||
| pvcpu | ||
| timer | ||
| xenpci | ||
| xenstore | ||