Re: [Qemu-devel] [RFC v4 16/21] blockjobs: add waiting status

2018-02-28 Thread Kevin Wolf 
Am 27.02.2018 um 21:50 hat John Snow geschrieben:
> 
> 
> On 02/27/2018 03:00 PM, Eric Blake wrote:
> > On 02/23/2018 05:51 PM, John Snow wrote:
> >> For jobs that are stuck waiting on others in a transaction, it would
> >> be nice to know that they are no longer "running" in that sense, but
> >> instead are waiting on other jobs in the transaction.
> >>
> >> Jobs that are "waiting" in this sense cannot be meaningfully altered
> >> any longer as they have left their running loop. The only meaningful
> >> user verb for jobs in this state is "cancel," which will cancel the
> >> whole transaction, too.
> >>
> >> Transitions:
> >> Running -> Waiting:   Normal transition.
> >> Ready   -> Waiting:   Normal transition.
> >> Waiting -> Aborting:  Transactional cancellation.
> >> Waiting -> Concluded: Normal transition.
> >>
> >> Removed Transitions:
> >> Running -> Concluded: Jobs must go to WAITING first.
> >> Ready   -> Concluded: Jobs must go to WAITING fisrt.
> > 
> > s/fisrt/first/
> > 
> >> +++ b/blockjob.c
> > 
> >> @@ -3934,6 +3938,29 @@
> >>   'offset': 'int',
> >>   'speed' : 'int' } }
> >>   +##
> >> +# @BLOCK_JOB_WAITING:
> >> +#
> >> +# Emitted when a block job that is part of a transction has stopped
> >> work and is
> > 
> > s/transction/transaction/
> > 
> >> +# waiting for other jobs in the transaction to reach the same state.
> > 
> > Is this event emitted only for 'new-style' transactions (old drivers
> > will never see it, because they don't request new style), or always (old
> > drivers will see, but presumably ignore, it)?
> > 
> 
> ...! Actually, I meant to remove the WAITING *event* entirely, this is a
> mistake.
> 
> It's purely an informational state that clients likely cannot make any
> real use of, because regardless of old or new style, jobs will
> transition automatically to "PENDING."
> 
> That said, old or new, the state is visible from query-block-jobs.

It means that the block job isn't working any more, which could possibly
be useful information.

Umm... When mirror transitions into WAITING, it stops working, but
doesn't change the graph yet. Isn't that a problem? Currently it doesn't
cause bugs because mirror doesn't support transactions, but we should
design things so that mirror could become transactionable later on.

I suppose one way to achieve this would be that mirror only transitions
into WAITING when the whole transaction is ready to move forward. In
this case, block-job-complete wouldn't tell mirror any more to actually
complete, but just to signal that the user is ready to have this job
completed.

Essentially this would split READY in two: The first state is when the
job has completed the bulk job and waits for the user, and the second
state is after the user sent block-job-complete. The second state
automatically transitions into WAITING as soon as all other jobs in the
transaction are either WAITING or in the second READY state.

Alternatively, mirror jobs could stay active in the WAITING phase, which
would then become the second READY phase. In this case, the state
machine would stay as it is, just the semantics of WAITING would change.

The result is either way that the WAITING event becomes uninteresting,
so after all I think I agree with completely removing it.

Kevin

Re: [Qemu-devel] [RFC v4 16/21] blockjobs: add waiting status

2018-02-27 Thread John Snow 


On 02/27/2018 03:00 PM, Eric Blake wrote:
> On 02/23/2018 05:51 PM, John Snow wrote:
>> For jobs that are stuck waiting on others in a transaction, it would
>> be nice to know that they are no longer "running" in that sense, but
>> instead are waiting on other jobs in the transaction.
>>
>> Jobs that are "waiting" in this sense cannot be meaningfully altered
>> any longer as they have left their running loop. The only meaningful
>> user verb for jobs in this state is "cancel," which will cancel the
>> whole transaction, too.
>>
>> Transitions:
>> Running -> Waiting:   Normal transition.
>> Ready   -> Waiting:   Normal transition.
>> Waiting -> Aborting:  Transactional cancellation.
>> Waiting -> Concluded: Normal transition.
>>
>> Removed Transitions:
>> Running -> Concluded: Jobs must go to WAITING first.
>> Ready   -> Concluded: Jobs must go to WAITING fisrt.
> 
> s/fisrt/first/
> 
>> +++ b/blockjob.c
> 
>> @@ -3934,6 +3938,29 @@
>>   'offset': 'int',
>>   'speed' : 'int' } }
>>   +##
>> +# @BLOCK_JOB_WAITING:
>> +#
>> +# Emitted when a block job that is part of a transction has stopped
>> work and is
> 
> s/transction/transaction/
> 
>> +# waiting for other jobs in the transaction to reach the same state.
> 
> Is this event emitted only for 'new-style' transactions (old drivers
> will never see it, because they don't request new style), or always (old
> drivers will see, but presumably ignore, it)?
> 

...! Actually, I meant to remove the WAITING *event* entirely, this is a
mistake.

It's purely an informational state that clients likely cannot make any
real use of, because regardless of old or new style, jobs will
transition automatically to "PENDING."

That said, old or new, the state is visible from query-block-jobs.

--js

Re: [Qemu-devel] [RFC v4 16/21] blockjobs: add waiting status

2018-02-27 Thread Eric Blake 

On 02/23/2018 05:51 PM, John Snow wrote:

For jobs that are stuck waiting on others in a transaction, it would
be nice to know that they are no longer "running" in that sense, but
instead are waiting on other jobs in the transaction.

Jobs that are "waiting" in this sense cannot be meaningfully altered
any longer as they have left their running loop. The only meaningful
user verb for jobs in this state is "cancel," which will cancel the
whole transaction, too.

Transitions:
Running -> Waiting:   Normal transition.
Ready   -> Waiting:   Normal transition.
Waiting -> Aborting:  Transactional cancellation.
Waiting -> Concluded: Normal transition.

Removed Transitions:
Running -> Concluded: Jobs must go to WAITING first.
Ready   -> Concluded: Jobs must go to WAITING fisrt.


s/fisrt/first/


+++ b/blockjob.c



@@ -3934,6 +3938,29 @@
  'offset': 'int',
  'speed' : 'int' } }
  
+##

+# @BLOCK_JOB_WAITING:
+#
+# Emitted when a block job that is part of a transction has stopped work and is


s/transction/transaction/


+# waiting for other jobs in the transaction to reach the same state.


Is this event emitted only for 'new-style' transactions (old drivers 
will never see it, because they don't request new style), or always (old 
drivers will see, but presumably ignore, it)?


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[Qemu-devel] [RFC v4 16/21] blockjobs: add waiting status

2018-02-23 Thread John Snow 
For jobs that are stuck waiting on others in a transaction, it would
be nice to know that they are no longer "running" in that sense, but
instead are waiting on other jobs in the transaction.

Jobs that are "waiting" in this sense cannot be meaningfully altered
any longer as they have left their running loop. The only meaningful
user verb for jobs in this state is "cancel," which will cancel the
whole transaction, too.

Transitions:
Running -> Waiting:   Normal transition.
Ready   -> Waiting:   Normal transition.
Waiting -> Aborting:  Transactional cancellation.
Waiting -> Concluded: Normal transition.

Removed Transitions:
Running -> Concluded: Jobs must go to WAITING first.
Ready   -> Concluded: Jobs must go to WAITING fisrt.

Verbs:
Cancel: Can be applied to WAITING jobs.

 +-+
 |UNDEFINED|
 +--+--+
|
 +--v+
 |CREATED+-+
 +--++ |
|  |
 +--v+ +--+|
   +-+RUNNING<->PAUSED||
   | +--+-+--+ +--+|
   || ||
   || +--+ |
   ||| |
   | +--v--+   +---+ | |
   +-+READY<--->STANDBY| | |
   | +--+--+   +---+ | |
   ||| |
   | +--v+   | |
   +-+WAITING<---+ |
   | +--++ |
   ||  |
+--+-+   +--v--+   |
|ABORTING+--->CONCLUDED|   |
++   +--+--+   |
|  |
 +--v-+|
 |NULL<+
 ++

Signed-off-by: John Snow 
---
 blockjob.c   | 37 -
 qapi/block-core.json | 29 -
 2 files changed, 48 insertions(+), 18 deletions(-)

diff --git a/blockjob.c b/blockjob.c
index 1c010ec100..4aed86fc6b 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -44,26 +44,27 @@ static QemuMutex block_job_mutex;
 
 /* BlockJob State Transition Table */
 bool BlockJobSTT[BLOCK_JOB_STATUS__MAX][BLOCK_JOB_STATUS__MAX] = {
-  /* U, C, R, P, Y, S, X, E, N */
-/* U: */ [BLOCK_JOB_STATUS_UNDEFINED] = {0, 1, 0, 0, 0, 0, 0, 0, 0},
-/* C: */ [BLOCK_JOB_STATUS_CREATED]   = {0, 0, 1, 0, 0, 0, 0, 0, 1},
-/* R: */ [BLOCK_JOB_STATUS_RUNNING]   = {0, 0, 0, 1, 1, 0, 1, 1, 0},
-/* P: */ [BLOCK_JOB_STATUS_PAUSED]= {0, 0, 1, 0, 0, 0, 0, 0, 0},
-/* Y: */ [BLOCK_JOB_STATUS_READY] = {0, 0, 0, 0, 0, 1, 1, 1, 0},
-/* S: */ [BLOCK_JOB_STATUS_STANDBY]   = {0, 0, 0, 0, 1, 0, 0, 0, 0},
-/* X: */ [BLOCK_JOB_STATUS_ABORTING]  = {0, 0, 0, 0, 0, 0, 0, 1, 0},
-/* E: */ [BLOCK_JOB_STATUS_CONCLUDED] = {0, 0, 0, 0, 0, 0, 0, 0, 1},
-/* N: */ [BLOCK_JOB_STATUS_NULL]  = {0, 0, 0, 0, 0, 0, 0, 0, 0},
+  /* U, C, R, P, Y, S, W, X, E, N */
+/* U: */ [BLOCK_JOB_STATUS_UNDEFINED] = {0, 1, 0, 0, 0, 0, 0, 0, 0, 0},
+/* C: */ [BLOCK_JOB_STATUS_CREATED]   = {0, 0, 1, 0, 0, 0, 0, 0, 0, 1},
+/* R: */ [BLOCK_JOB_STATUS_RUNNING]   = {0, 0, 0, 1, 1, 0, 1, 1, 0, 0},
+/* P: */ [BLOCK_JOB_STATUS_PAUSED]= {0, 0, 1, 0, 0, 0, 0, 0, 0, 0},
+/* Y: */ [BLOCK_JOB_STATUS_READY] = {0, 0, 0, 0, 0, 1, 1, 1, 0, 0},
+/* S: */ [BLOCK_JOB_STATUS_STANDBY]   = {0, 0, 0, 0, 1, 0, 0, 0, 0, 0},
+/* W: */ [BLOCK_JOB_STATUS_WAITING]   = {0, 0, 0, 0, 0, 0, 0, 1, 1, 0},
+/* X: */ [BLOCK_JOB_STATUS_ABORTING]  = {0, 0, 0, 0, 0, 0, 0, 0, 1, 0},
+/* E: */ [BLOCK_JOB_STATUS_CONCLUDED] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 1},
+/* N: */ [BLOCK_JOB_STATUS_NULL]  = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
 };
 
 bool BlockJobVerbTable[BLOCK_JOB_VERB__MAX][BLOCK_JOB_STATUS__MAX] = {
-  /* U, C, R, P, Y, S, X, E, N */
-[BLOCK_JOB_VERB_CANCEL]   = {0, 1, 1, 1, 1, 1, 0, 0, 0},
-[BLOCK_JOB_VERB_PAUSE]= {0, 1, 1, 1, 1, 1, 0, 0, 0},
-[BLOCK_JOB_VERB_RESUME]   = {0, 1, 1, 1, 1, 1, 0, 0, 0},
-[BLOCK_JOB_VERB_SET_SPEED]= {0, 1, 1, 1, 1, 1, 0, 0, 0},
-[BLOCK_JOB_VERB_COMPLETE] = {0, 0, 0, 0, 1, 0, 0, 0, 0},
-[BLOCK_JOB_VERB_DISMISS]  = {0, 0, 0, 0, 0, 0, 0, 1, 0},
+  /* U, C, R, P, Y, S, W, X, E, N */
+[BLOCK_JOB_VERB_CANCEL]   = {0, 1, 1, 1, 1, 1, 1, 0, 0, 0},
+[BLOCK_JOB_VERB_PAUSE]= {0, 1, 1, 1, 1, 1, 0, 0, 0, 0},
+[BLOCK_JOB_VERB_RESUME]   = {0, 1, 1, 1, 1, 1, 0, 0, 0, 0},
+[BLOCK_JOB_VERB_SET_SPEED]= {0, 1, 1, 1, 1, 1, 0, 0, 0, 0},
+[BLOCK_JOB_VERB_COMPLETE] = {0, 0, 0, 0, 1, 0, 0,