[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 00/23] backup performance: block_status + async

From: Max Reitz
Subject: Re: [PATCH v4 00/23] backup performance: block_status + async
Date: Mon, 18 Jan 2021 16:07:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0

On 16.01.21 22:46, Vladimir Sementsov-Ogievskiy wrote:
Hi Max!
I applied my series onto yours 129-fixing and found, that 129 fails for backup.
And setting small max-chunk and even max-workers to 1 doesn't help! (setting
speed like in v3 still helps).

And I found, that the problem is that really, the whole backup job goes during
drain, because in new architecture we do just job_yield() during the whole
background block-copy.

OK, so as it was in v3, the job was drained, but since it was already yielding while block-copy was running in the background, nothing happened; the block-copy completed and only then was the job woken (and then there was no reason to pause, because it was done already).

So now the job is entered on drain, too (not only user pauses), which means that it gets a chance to pause background requests.

In backup’s case, that means invoking job_yield() again, which sets a job_pause_point(), which will cancel the block-copy. Once the job is unpaused (re-entered by job_resume()), backup sees block-copy is cancelled (and finished), leaves the loop, and retries with a new block-copy call.

I think I got it now.

So all that’s left is issuing a thanks to you – thanks! – and announcing that I’ve applied this series to my block branch (with s/not unsupported/not supported/ in patch 23):



reply via email to

[Prev in Thread] Current Thread [Next in Thread]