Am 05.03.2018 um 12:45 schrieb Stefan Hajnoczi: > On Thu, Feb 22, 2018 at 12:13:50PM +0100, Peter Lieven wrote: >> I stumbled across the MAX_INFLIGHT_IO field that was introduced in 2015 and >> was curious what was the reason >> to choose 512MB as readahead? The question is that I found that the source >> VM gets very unresponsive I/O wise >> while the initial 512MB are read and furthermore seems to stay unreasponsive >> if we choose a high migration speed >> and have a fast storage on the destination VM. >> >> In our environment I modified this value to 16MB which seems to work much >> smoother. I wonder if we should make >> this a user configurable value or define a different rate limit for the >> block transfer in bulk stage at least? > I don't know if benchmarks were run when choosing the value. From the > commit description it sounds like the main purpose was to limit the > amount of memory that can be consumed. > > 16 MB also fulfills that criteria :), but why is the source VM more > responsive with a lower value? > > Perhaps the issue is queue depth on the storage device - the block > migration code enqueues up to 512 MB worth of reads, and guest I/O has > to wait?
That is my guess. Especially if the destination storage is faster we basically alsways have 512 I/Os in flight on the source storage. Does anyone mind if the reduce that value to 16MB or do we need a better mechanism? Peter
