qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 00/40] Generic background jobs


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v2 00/40] Generic background jobs
Date: Tue, 22 May 2018 13:01:14 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 18.05.2018 um 20:41 hat Dr. David Alan Gilbert geschrieben:
> * Kevin Wolf (address@hidden) wrote:
> > Before we can make x-blockdev-create a background job, we need to
> > generalise the job infrastructure so that it can be used without any
> > associated block node.
> 
> Is there any relationship between what this does, and what
> Marc-André's 'monitor: add asynchronous command type' tries to do?
> (See address@hidden 26th March)

Depends on who you ask. :-)

In a way, yes. Marc-André's async commands are for long-running
operations and jobs are for long-running operations. However, they are
for a different kind of "long-running".

Basically, Marc-André's work is for commands that are generally quick,
but perform some blocking operation. Usually commands that are currently
implemented synchronously, but always bothered us because they block the
VM for a while. They take maybe a few seconds at most, but you really
don't want them to block the guest even for short time.

The important part here is you don't want to modify the operations while
they're running, they just send their return value when they are done.
(In the latest version, Marc-André even made sure not to modify the wire
protocol, so IIUC the commands aren't really async any more in the sense
that you can have multiple commands running, but they are just
non-blocking in the sense that the guest can keep running while they are
doing their work.)

In comparison, jobs are typically really long running, like several
minutes (like copying a whole disk image). Some of them can even run
indefinitely (like mirroring) until you explicitly tell them to stop.
You want to continue using the monitor while they are running, and to be
able to manage them at runtime (pause/resume/set speed/cancel/...).

So I think both address different problems.

Kevin



reply via email to

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