[Qemu-devel] question about concurrent block job

[Qemu-devel] question about concurrent block job

[Zhangleiqiang]

Hi, Paolo:
	I found qemu does not support concurrently running multiple block jobs of the same drive (limited by the bs->in_use field).  But there are indeed some type of block job can run concurrently, such as running block stream job while running drive mirror, etc.  Am I right ? Is it necessary to introduce the concurrency mechanism in qemu ?

	Thanks.

----------
Leiqzhang

Best Regards

Re: [Qemu-devel] question about concurrent block job

[Stefan Hajnoczi]

On Wed, Apr 24, 2013 at 12:28 PM, Zhangleiqiang
<zhangleiqiang@huawei.com> wrote:
>         I found qemu does not support concurrently running multiple block jobs of the same drive (limited by the bs->in_use field).  But there are indeed some type of block job can run concurrently, such as running block stream job while running drive mirror, etc.  Am I right ? Is it necessary to introduce the concurrency mechanism in qemu ?

stream and mirror both switch to the destination image file when they
complete.  I'm not sure it makes sense to run both at the same time.
Some of the block jobs can interfere with each other, so it's simplest
to only allow one.

Enabling multiple jobs at the same time will require a lot of care,
including extending the HMP/QMP APIs to deal with multiple jobs.
bs->job is a scalar field at the moment.

Stefan

Re: [Qemu-devel] question about concurrent block job

[Zhangleiqiang]

Hi, Stefan:
	Thanks for your relay.

	There are some jobs like drive-mirror, can keep running continuously (without --finish/--pivort option ). While the mirroring, we may need to run other block jobs, e.g. running block-commit or block-stream to decrease the length of the image chain so that the vm's perf can be improved. 
	Although I am also agree that it will require a lot of care, the ability for enabling multiple jobs at the same time does make sence under some scenario.


> -----Original Message-----
> From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> Sent: Wednesday, April 24, 2013 9:55 PM
> To: Zhangleiqiang
> Cc: Paolo Bonzini; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] question about concurrent block job
> 
> On Wed, Apr 24, 2013 at 12:28 PM, Zhangleiqiang
> <zhangleiqiang@huawei.com> wrote:
> >         I found qemu does not support concurrently running multiple block
> jobs of the same drive (limited by the bs->in_use field).  But there are indeed
> some type of block job can run concurrently, such as running block stream job
> while running drive mirror, etc.  Am I right ? Is it necessary to introduce the
> concurrency mechanism in qemu ?
> 
> stream and mirror both switch to the destination image file when they
> complete.  I'm not sure it makes sense to run both at the same time.
> Some of the block jobs can interfere with each other, so it's simplest
> to only allow one.

> Enabling multiple jobs at the same time will require a lot of care,
> including extending the HMP/QMP APIs to deal with multiple jobs.
> bs->job is a scalar field at the moment.
> 
> Stefan


----------
Leiqzhang

Best Regards

Re: [Qemu-devel] question about concurrent block job

[Zhangleiqiang]

Hi, Stefan:
	May be the "in_use" flag of "bs" at the "drive" unit is too large. Perhaps the "in_use" flag should just lock at the unit of one or some "image(s)" in the image chain, the "image(s)" needed to be locked are always the ones will be write during the job.

	E.g. "drive_mirror" lock the "snapshot-file", "block-commit" lock the dst image of the commit job, etc.


----------
Leiqzhang

Best Regards


> -----Original Message-----
> From: Zhangleiqiang
> Sent: Thursday, April 25, 2013 9:27 AM
> To: Stefan Hajnoczi
> Cc: Paolo Bonzini; qemu-devel@nongnu.org; Zhangleiqiang
> Subject: RE: [Qemu-devel] question about concurrent block job
> 
> Hi, Stefan:
> 	Thanks for your relay.
> 
> 	There are some jobs like drive-mirror, can keep running continuously
> (without --finish/--pivort option ). While the mirroring, we may need to run
> other block jobs, e.g. running block-commit or block-stream to decrease the
> length of the image chain so that the vm's perf can be improved.
> 	Although I am also agree that it will require a lot of care, the ability for
> enabling multiple jobs at the same time does make sence under some scenario.
> 
> 
> > -----Original Message-----
> > From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> > Sent: Wednesday, April 24, 2013 9:55 PM
> > To: Zhangleiqiang
> > Cc: Paolo Bonzini; qemu-devel@nongnu.org
> > Subject: Re: [Qemu-devel] question about concurrent block job
> >
> > On Wed, Apr 24, 2013 at 12:28 PM, Zhangleiqiang
> > <zhangleiqiang@huawei.com> wrote:
> > >         I found qemu does not support concurrently running multiple
> block
> > jobs of the same drive (limited by the bs->in_use field).  But there are indeed
> > some type of block job can run concurrently, such as running block stream job
> > while running drive mirror, etc.  Am I right ? Is it necessary to introduce the
> > concurrency mechanism in qemu ?
> >
> > stream and mirror both switch to the destination image file when they
> > complete.  I'm not sure it makes sense to run both at the same time.
> > Some of the block jobs can interfere with each other, so it's simplest
> > to only allow one.
> 
> > Enabling multiple jobs at the same time will require a lot of care,
> > including extending the HMP/QMP APIs to deal with multiple jobs.
> > bs->job is a scalar field at the moment.
> >
> > Stefan
> 
> 
> ----------
> Leiqzhang
> 
> Best Regards

Re: [Qemu-devel] question about concurrent block job

[Stefan Hajnoczi]

On Thu, Apr 25, 2013 at 01:59:23AM +0000, Zhangleiqiang wrote:
> 	May be the "in_use" flag of "bs" at the "drive" unit is too large. Perhaps the "in_use" flag should just lock at the unit of one or some "image(s)" in the image chain, the "image(s)" needed to be locked are always the ones will be write during the job.
> 
> 	E.g. "drive_mirror" lock the "snapshot-file", "block-commit" lock the dst image of the commit job, etc.

Choosing a finer-grained approach is not too hard.

The tricky parts are:

1. Extending the QMP API to support multiple block jobs.  Old clients
   only know how to deal with 1 block job but they should continue to
   work.

2. Thinking through all block jobs and their possible interactions.

Stefan

Re: [Qemu-devel] question about concurrent block job

[Zhangleiqiang]

Hi, Stefan:

> The tricky parts are:
> 
> 1. Extending the QMP API to support multiple block jobs.  Old clients
>    only know how to deal with 1 block job but they should continue to
>    work.

I think the block-job related qmp commands which are needed to change are as follows:

1. cmds for job control:  block-job-set-speed, block-job-cancel, block-job-pause, block-job-resume, block-job-complete
2. cmds for job query:   query-block-jobs

In order to make sure that old clients keep working, the job control cmds can add one optional argument of "job_id". If the arg of "job_id" is not assigned, then the cmd will affect all the running jobs. 
The "job_id" may be returned by the corresponding job start command and the "query-block-jobs" command.

For example:

-> drive-mirror device=drive0 target=/path/to/dest.snap sync=full
<- {u'return': {"job_id": 123}}

-> query-block-jobs
<- {u'return': [{u'busy': True, u'type': u'mirror', u'len': 8589934592, u'paused': False, u'io-status': u'ok', u'offset': 4483579904, u'device': u'drive0', u'speed': 1, u'job_id': 123}, {u'busy': True, u'type': u'commit', u'len': 1073741824, u'paused': False, u'io-status': u'ok', u'offset': 1073741824, u'device': u'drive0', u'speed': 1, u'job_id': 122}]}

->block-job-cancel job_id=123
<- {u'return': {}}



----------
Leiqzhang

Best Regards


> -----Original Message-----
> From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
> Sent: Thursday, April 25, 2013 8:12 PM
> To: Zhangleiqiang
> Cc: Paolo Bonzini; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] question about concurrent block job
> 
> On Thu, Apr 25, 2013 at 01:59:23AM +0000, Zhangleiqiang wrote:
> > 	May be the "in_use" flag of "bs" at the "drive" unit is too large. Perhaps
> the "in_use" flag should just lock at the unit of one or some "image(s)" in the
> image chain, the "image(s)" needed to be locked are always the ones will be
> write during the job.
> >
> > 	E.g. "drive_mirror" lock the "snapshot-file", "block-commit" lock the dst
> image of the commit job, etc.
> 
> Choosing a finer-grained approach is not too hard.
> 
> The tricky parts are:
> 
> 1. Extending the QMP API to support multiple block jobs.  Old clients
>    only know how to deal with 1 block job but they should continue to
>    work.
> 
> 2. Thinking through all block jobs and their possible interactions.
> 
> Stefan