qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-block@nongnu.org, pkrempa@redhat.com, jtc@redhat.com,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC v4 05/21] blockjobs: add state transition table
Date: Tue, 27 Feb 2018 11:45:38 -0500	[thread overview]
Message-ID: <0b9a7368-0425-8879-91db-3c1b3049912e@redhat.com> (raw)
In-Reply-To: <20180227162759.GB5269@localhost.localdomain>



On 02/27/2018 11:27 AM, Kevin Wolf wrote:
> Am 24.02.2018 um 00:51 hat John Snow geschrieben:
>> The state transition table has mostly been implied. We're about to make
>> it a bit more complex, so let's make the STM explicit instead.
>>
>> Perform state transitions with a function that for now just asserts the
>> transition is appropriate.
>>
>> Transitions:
>> Undefined -> Created: During job initialization.
>> Created   -> Running: Once the job is started.
>>                       Jobs cannot transition from "Created" to "Paused"
>>                       directly, but will instead synchronously transition
>>                       to running to paused immediately.
>> Running   -> Paused:  Normal workflow for pauses.
>> Running   -> Ready:   Normal workflow for jobs reaching their sync point.
>>                       (e.g. mirror)
>> Ready     -> Standby: Normal workflow for pausing ready jobs.
>> Paused    -> Running: Normal resume.
>> Standby   -> Ready:   Resume of a Standby job.
>>
>>
>> +---------+
>> |UNDEFINED|
>> +--+------+
>>    |
>> +--v----+
>> |CREATED|
>> +--+----+
>>    |
>> +--v----+     +------+
>> |RUNNING<----->PAUSED|
>> +--+----+     +------+
>>    |
>> +--v--+       +-------+
>> |READY<------->STANDBY|
>> +-----+       +-------+
>>
>>
>> Notably, there is no state presently defined as of this commit that
>> deals with a job after the "running" or "ready" states, so this table
>> will be adjusted alongside the commits that introduce those states.
>>
>> Signed-off-by: John Snow <jsnow@redhat.com>
>> ---
>>  block/trace-events |  3 +++
>>  blockjob.c         | 42 ++++++++++++++++++++++++++++++++++++------
>>  2 files changed, 39 insertions(+), 6 deletions(-)
>>
>> diff --git a/block/trace-events b/block/trace-events
>> index 02dd80ff0c..b75a0c8409 100644
>> --- a/block/trace-events
>> +++ b/block/trace-events
>> @@ -4,6 +4,9 @@
>>  bdrv_open_common(void *bs, const char *filename, int flags, const char *format_name) "bs %p filename \"%s\" flags 0x%x format_name \"%s\""
>>  bdrv_lock_medium(void *bs, bool locked) "bs %p locked %d"
>>  
>> +# blockjob.c
>> +block_job_state_transition(void *job,  int ret, const char *legal, const char *s0, const char *s1) "job %p (ret: %d) attempting %s transition (%s-->%s)"
>> +
>>  # block/block-backend.c
>>  blk_co_preadv(void *blk, void *bs, int64_t offset, unsigned int bytes, int flags) "blk %p bs %p offset %"PRId64" bytes %u flags 0x%x"
>>  blk_co_pwritev(void *blk, void *bs, int64_t offset, unsigned int bytes, int flags) "blk %p bs %p offset %"PRId64" bytes %u flags 0x%x"
>> diff --git a/blockjob.c b/blockjob.c
>> index 1be9c20cff..d745b3bb69 100644
>> --- a/blockjob.c
>> +++ b/blockjob.c
>> @@ -28,6 +28,7 @@
>>  #include "block/block.h"
>>  #include "block/blockjob_int.h"
>>  #include "block/block_int.h"
>> +#include "block/trace.h"
>>  #include "sysemu/block-backend.h"
>>  #include "qapi/error.h"
>>  #include "qapi/qmp/qerror.h"
>> @@ -41,6 +42,34 @@
>>   * block_job_enter. */
>>  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 */
>> +    /* U: */ [BLOCK_JOB_STATUS_UNDEFINED] = {0, 1, 0, 0, 0, 0},
> 
> Even at the end of the series, this is the only use of
> BLOCK_JOB_STATUS_UNDEFINED.
> 
>> +    /* C: */ [BLOCK_JOB_STATUS_CREATED]   = {0, 0, 1, 0, 0, 0},
>> +    /* R: */ [BLOCK_JOB_STATUS_RUNNING]   = {0, 0, 0, 1, 1, 0},
>> +    /* P: */ [BLOCK_JOB_STATUS_PAUSED]    = {0, 0, 1, 0, 0, 0},
>> +    /* Y: */ [BLOCK_JOB_STATUS_READY]     = {0, 0, 0, 0, 0, 1},
>> +    /* S: */ [BLOCK_JOB_STATUS_STANDBY]   = {0, 0, 0, 0, 1, 0},
>> +};
>> +
>> +static void block_job_state_transition(BlockJob *job, BlockJobStatus s1)
>> +{
>> +    BlockJobStatus s0 = job->status;
>> +    if (s0 == s1) {
>> +        return;
>> +    }
>> +    assert(s1 >= 0 && s1 <= BLOCK_JOB_STATUS__MAX);
>> +    trace_block_job_state_transition(job, job->ret, BlockJobSTT[s0][s1] ?
>> +                                     "allowed" : "disallowed",
>> +                                     qapi_enum_lookup(&BlockJobStatus_lookup,
>> +                                                      s0),
>> +                                     qapi_enum_lookup(&BlockJobStatus_lookup,
>> +                                                      s1));
>> +    assert(BlockJobSTT[s0][s1]);
>> +    job->status = s1;
>> +}
>> +
>>  static void block_job_lock(void)
>>  {
>>      qemu_mutex_lock(&block_job_mutex);
>> @@ -320,7 +349,7 @@ void block_job_start(BlockJob *job)
>>      job->pause_count--;
>>      job->busy = true;
>>      job->paused = false;
>> -    job->status = BLOCK_JOB_STATUS_RUNNING;
>> +    block_job_state_transition(job, BLOCK_JOB_STATUS_RUNNING);
>>      bdrv_coroutine_enter(blk_bs(job->blk), job->co);
>>  }
>>  
>> @@ -704,6 +733,7 @@ void *block_job_create(const char *job_id, const BlockJobDriver *driver,
>>      job->refcnt        = 1;
>>      job->manual        = (flags & BLOCK_JOB_MANUAL);
>>      job->status        = BLOCK_JOB_STATUS_CREATED;
>> +    block_job_state_transition(job, BLOCK_JOB_STATUS_CREATED);
> 
> So did you intend to start with BLOCK_JOB_STATUS_UNDEFINED and then
> transition to BLOCK_JOB_STATUS_CREATED?
> 
> Or should we completely remove BLOCK_JOB_STATUS_UNDEFINED, keep the
> initialisation and not call block_job_state_transition() here?
> 
> Kevin
> 

We can do that;

I had it start as "Undefined" because I liked how a g_new0() object will
default to that state, so it felt "safe."

On the negatives, it does mean that technically you COULD witness a job
in this state if QEMU did something wrong, which would be confusing
because you wouldn't be able to fix it via QMP.

--js

  reply	other threads:[~2018-02-27 16:45 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-23 23:51 [Qemu-devel] [RFC v4 00/21] blockjobs: add explicit job management John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 01/21] blockjobs: fix set-speed kick John Snow
2018-02-27 16:32   ` Eric Blake
2018-02-27 17:18   ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 02/21] blockjobs: model single jobs as transactions John Snow
2018-02-27 16:36   ` Eric Blake
2018-02-27 17:18   ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 03/21] blockjobs: add manual property John Snow
2018-02-27 16:39   ` Eric Blake
2018-02-27 17:18   ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 04/21] blockjobs: add status enum John Snow
2018-02-27 16:44   ` Eric Blake
2018-02-27 17:19   ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 05/21] blockjobs: add state transition table John Snow
2018-02-27 16:27   ` Kevin Wolf
2018-02-27 16:45     ` John Snow [this message]
2018-02-27 17:08       ` Kevin Wolf
2018-02-27 18:58         ` John Snow
2018-02-27 18:58   ` Eric Blake
2018-02-27 19:06     ` John Snow
2018-02-27 19:22     ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 06/21] iotests: add pause_wait John Snow
2018-02-27 17:19   ` Kevin Wolf
2018-02-27 19:01   ` Eric Blake
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 07/21] blockjobs: add block_job_verb permission table John Snow
2018-02-27 17:19   ` Kevin Wolf
2018-02-27 19:25   ` Eric Blake
2018-02-27 19:38     ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 08/21] blockjobs: add ABORTING state John Snow
2018-02-27 19:34   ` Eric Blake
2018-02-28 14:54   ` Kevin Wolf
2018-02-28 19:26     ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 09/21] blockjobs: add CONCLUDED state John Snow
2018-02-27 19:38   ` Eric Blake
2018-02-27 19:44     ` John Snow
2018-02-28 15:37   ` Kevin Wolf
2018-02-28 19:29     ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 10/21] blockjobs: add NULL state John Snow
2018-02-27 19:41   ` Eric Blake
2018-02-28 15:42   ` Kevin Wolf
2018-02-28 20:04     ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 11/21] blockjobs: add block_job_dismiss John Snow
2018-02-27 19:44   ` Eric Blake
2018-02-28 15:53   ` Kevin Wolf
2018-02-28 20:35     ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 12/21] blockjobs: ensure abort is called for cancelled jobs John Snow
2018-02-27 19:49   ` Eric Blake
2018-02-27 20:43     ` John Snow
2018-02-28 16:05   ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 13/21] blockjobs: add commit, abort, clean helpers John Snow
2018-02-27 19:50   ` Eric Blake
2018-02-28 16:07   ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 14/21] blockjobs: add block_job_txn_apply function John Snow
2018-02-27 19:52   ` Eric Blake
2018-02-28 16:32   ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 15/21] blockjobs: add prepare callback John Snow
2018-02-27 19:56   ` Eric Blake
2018-02-27 20:45     ` John Snow
2018-02-28 17:04   ` Kevin Wolf
2018-03-07  3:19     ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 16/21] blockjobs: add waiting status John Snow
2018-02-27 20:00   ` Eric Blake
2018-02-27 20:50     ` John Snow
2018-02-28 17:46       ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 17/21] blockjobs: add PENDING status and event John Snow
2018-02-27 20:05   ` Eric Blake
2018-02-27 20:54     ` John Snow
2018-02-28 17:55   ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 18/21] blockjobs: add block-job-finalize John Snow
2018-02-27 20:13   ` Eric Blake
2018-02-28 18:15   ` Kevin Wolf
2018-02-28 19:14     ` John Snow
2018-03-01 10:01       ` Kevin Wolf
2018-03-01 19:24         ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 19/21] blockjobs: Expose manual property John Snow
2018-02-27 20:16   ` Eric Blake
2018-02-27 20:42     ` John Snow
2018-02-27 21:57     ` John Snow
2018-02-27 22:27       ` Eric Blake
2018-02-28 18:23       ` Kevin Wolf
2018-02-28 19:19         ` John Snow
2018-02-28 18:25   ` Kevin Wolf
2018-02-28 19:20     ` John Snow
2018-02-28 19:27       ` [Qemu-devel] [Qemu-block] " Eric Blake
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 20/21] iotests: test manual job dismissal John Snow
2018-02-27 20:21   ` Eric Blake
2018-02-27 20:41     ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 21/21] blockjobs: add manual_mgmt option to transactions John Snow
2018-02-27 20:24   ` Eric Blake
2018-02-28 18:29     ` Kevin Wolf
2018-02-28 19:24       ` John Snow
2018-03-01 10:10         ` Kevin Wolf
2018-02-24  0:30 ` [Qemu-devel] [RFC v4 00/21] blockjobs: add explicit job management no-reply
2018-02-24 14:31 ` no-reply
2018-02-27 21:01   ` John Snow
2018-02-28 18:32     ` Kevin Wolf
2018-02-25 23:25 ` no-reply
2018-02-27 20:58   ` John Snow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0b9a7368-0425-8879-91db-3c1b3049912e@redhat.com \
    --to=jsnow@redhat.com \
    --cc=jtc@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).