[Xen-devel] blktap wedges when block-attached to dom0

[jake <jwires@xxxxxxxxxxxxx>]

blktap devices attached to dom0 are liable to wedge during IO transfers.
The problem does not occur in typical usage scenarios (i.e., virtual
devices attached to guest domains); it is unique to the unanticipated
case in which virtual devices are attached to dom0. 

The problem arises when processes in dom0 generate a large number of
dirty pages while writing to a block-attached device.  Once the number
of dirty pages reaches a certain threshold, the dom0 kernel begins
throttling IO in balance_dirty_pages; processes traversing the buffered
IO path will block in this function until the number of dirty pages
decreases. 

This is bad for the tapdisk process, which is responsible for servicing
IO requests from the blktap driver.  The tapdisk process normally
performs direct IO, but if it writes to a hole in a sparse file, it
falls into the buffered IO path.  If the tapdisk process blocks in
balance_dirty_pages, it will do so indefinitely, because it is the only
process that cleans the pages dirtied by the processes writing to the
virtual device.  Thus dirty pages continue to amass in dom0 as IO is
performed on the virtual device, but none of them make it to the
physical devices because the tapdisk process is unable to service the
requests. 

Note that when used as originally intended, blktap does not suffer from
this problem: when blktap devices are attached to guest domains,
performing IO on them dirties pages in the guest domain, not in dom0, so
the tapdisk process doesn't get throttled in balance_dirty_pages.

Attached is a patch that eschews the dom0 problem by exempting the
tapdisk process from blocking in balance_dirty_pages.  tapdisk processes
servicing dom0-attached devices are granted special status using a
modified setpriority syscall; a check in balance_dirty_pages ensures
that such processes do not block indefinitely. 

This is clearly a hacky solution; any suggestions for improvement are
welcome.

blktap-dom0-attach.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel