Konrad, Roger, we've recently had a report of stuck I/O (with slightly over a hundred frontend instances in a single guest), which turned out to be a simple lack of configured grants on the system. This raises two questions:
1) Shouldn't blkfront cope with this situation, by throttling I/O (but not getting stuck), perhaps by forcing requests to be split (or splitting them itself) if gnttab_alloc_grant_references() continues to fail over a measurable time period? 2) Isn't the current grant hunger of blkfront a little extreme? An instance with all defaults can consume 1k grants (32 segs times 32 reqs), but the scaling with ring size, queue count, and number of segs can easily get this to 64k or more. A default configured host, however, allows only for 128k grants (256 frames each holding 512 entries). Interestingly I've found https://groups.google.com/forum/#!topic/linux.kernel/N6Q171xkIkM when looking around - is there a reason this or something similar never made it into the driver? Without such adjustment a single spike in I/O can lead to a significant amount of grants to be "lost" in the queue of a single frontend instance. Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
