qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org,
	armbru@redhat.com
Subject: Re: [Qemu-devel] [RFC 2/3] QMP: rate limit BLOCK_IO_ERROR
Date: Mon, 11 Aug 2014 09:17:19 +0100	[thread overview]
Message-ID: <20140811081719.GA11762@redhat.com> (raw)
In-Reply-To: <1406121438-23083-3-git-send-email-lcapitulino@redhat.com>

On Wed, Jul 23, 2014 at 09:17:17AM -0400, Luiz Capitulino wrote:
> This event has the same characteristics of the other rate-limited
> events, mainly we can emit dozens of it. Rate limit it then.
> 
> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> ---
>  monitor.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/monitor.c b/monitor.c
> index 5bc70a6..33abe6c 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -589,6 +589,7 @@ static void monitor_qapi_event_init(void)
>      monitor_qapi_event_throttle(QAPI_EVENT_QUORUM_REPORT_BAD, 1000);
>      monitor_qapi_event_throttle(QAPI_EVENT_QUORUM_FAILURE, 1000);
>      monitor_qapi_event_throttle(QAPI_EVENT_VSERPORT_CHANGE, 1000);
> +    monitor_qapi_event_throttle(QAPI_EVENT_BLOCK_IO_ERROR, 1000);


The rate limiting code only rate limits at the granularity of
individual event types. If there is context sensitive data associated
with events then the rate limiting will cause problems for applications
tracking the events.

eg consider with the simpler RTC CHANGE events if we get

   QAPI_EVENT_RTC_CHANGE offset=30
   QAPI_EVENT_RTC_CHANGE offset=700
   QAPI_EVENT_RTC_CHANGE offset=340

then rate limiting will mean that the application only receives

   QAPI_EVENT_RTC_CHANGE offset=340

This is fine because the application will always end up with a correct
view of the current system state.


For the BLOCK IO ERROR events this does not work because the events are
device and operation specific.

  QAPI_EVENT_BLOCK_IO_ERROR dev=ide0-hd1 op=read action=stop
  QAPI_EVENT_BLOCK_IO_ERROR dev=scsi1-hd2 op=write action=stop
  QAPI_EVENT_BLOCK_IO_ERROR dev=ide0-hd1 op=write action=stop

with throttling the app wll only receive

  QAPI_EVENT_BLOCK_IO_ERROR dev=ide0-hd1 op=write action=stop

which means it will have an *incorrect* view of the system state because
the info about  scsi1-hd2 is irretrievably lost, likewise info about the
read operation of ide0-hd1.

If you want to throttle BLOCK IO ERROR events, then you need to make the
monitor throttling more intelligent, so that it hashes on all the contextual
state. In this case you'd have to throttle based on (event, dev, op) to get
correct application behaviour.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

  parent reply	other threads:[~2014-08-11  8:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-23 13:17 [Qemu-devel] [RFC 0/3] QMP: extend BLOCK_IO_ERROR event Luiz Capitulino
2014-07-23 13:17 ` [Qemu-devel] [RFC 1/3] qapi: block-core.json: improve query-block doc Luiz Capitulino
2014-08-05 12:13   ` Eric Blake
2014-07-23 13:17 ` [Qemu-devel] [RFC 2/3] QMP: rate limit BLOCK_IO_ERROR Luiz Capitulino
2014-08-05 12:14   ` Eric Blake
2014-08-11  8:17   ` Daniel P. Berrange [this message]
2014-08-11 11:07     ` Markus Armbruster
2014-08-11 11:15       ` Daniel P. Berrange
2014-08-17  6:08         ` Paolo Bonzini
2014-08-14 13:13     ` Luiz Capitulino
2014-07-23 13:17 ` [Qemu-devel] [RFC 3/3] QMP: extend BLOCK_IO_ERROR event with no-space indicator Luiz Capitulino
2014-08-05 12:19   ` Eric Blake
2014-08-14 13:07     ` Luiz Capitulino
2014-08-05  9:13 ` [Qemu-devel] [RFC 0/3] QMP: extend BLOCK_IO_ERROR event Kevin Wolf
2014-08-14 13:05   ` Luiz Capitulino

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=20140811081719.GA11762@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=pbonzini@redhat.com \
    --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).