qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Chao Fan <fanc.fnst@cn.fujitsu.com>
Cc: Juan Quintela <quintela@redhat.com>,
	eblake@redhat.com, dgilbert@redhat.com, qemu-devel@nongnu.org,
	caoj.fnst@cn.fujitsu.com, douly.fnst@cn.fujitsu.com,
	maozy.fnst@cn.fujitsu.com, Li Zhijian <lizhijian@cn.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH] Output dirty-bytes-rate instead of dirty-pages-rate
Date: Wed, 15 Mar 2017 09:42:07 +0000	[thread overview]
Message-ID: <20170315094207.GD7770@redhat.com> (raw)
In-Reply-To: <20170315041358.GA2818@localhost.localdomain>

On Wed, Mar 15, 2017 at 12:13:58PM +0800, Chao Fan wrote:
> On Tue, Mar 14, 2017 at 12:37:30PM +0000, Daniel P. Berrange wrote:
> >On Tue, Mar 14, 2017 at 01:29:43PM +0100, Juan Quintela wrote:
> >> Chao Fan <fanc.fnst@cn.fujitsu.com> wrote:
> >> > In hmp, dirty-bytes-rate is more friendly than dirty-pages-rate.
> >> > It's also better for other tools to determine the cpu throttle
> >> > value in different architecture.
> >> >
> >> > Signed-off-by: Chao Fan <fanc.fnst@cn.fujitsu.com>
> >> > Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
> >> 
> >> I agree with Daniel here, you can't change the meaning of a field.  Look
> >> at skipped pages.  It is zero know because it is not used anymore, but
> >> we can't drop it.
> >> 
> >> I think it is better to expose page_size.  We have now
> >> 
> >> trasferred: bytes
> >> total: bytes
> >> duplicate: number of zero pages
> >> skipped: always zero.
> >> normal: number of normal pages
> >> normal_bytes: the same  in bytes
> >> mbps: megabytes per second?  I can't even remember this one
> >> dirty_sync_count: number of times we have go through the whole memory
> >> postcopy_requests = number of pages asked by postcopy faults?
> >> dirty_pages_rate = pages by some kind of unit
> >> 
> >> And we haven't yet started with compression or xbzrle.  I think that the
> >> best approach at this point is putting everything in pages except the
> >> things that don't make sense.
> >> 
> >> We can put everything on bytes, but then everything is HUGE.
> >> 
> >> Anyways, what do libvirt/management apps preffer?
> >
> >Since we have many fields already which are reported as page counts, I
> >think just adding page size would be preferrable to having twice as many
> >fields reported duplicating bytes + pages.
> >
> >The only reason to favour duplicating all fields to report bytes, is if
> >we needed to vary page size to deal with huge pages (eg if some reported
> >pages were 4kb and other reported pages with 2MB). You can easily just
> >scale huge pages counts to be "normal"  pages for purpose of reporting
> >though.
> 
> I am wondering if it's OK to expose page_size in qmp or hmp, just like
> a new command 'info page_size'.
> If confirmed,I will make the new patch.

I'd suggest having it as a field of "info migrate"

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

  reply	other threads:[~2017-03-15  9:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-14 10:27 [Qemu-devel] [PATCH] Output dirty-bytes-rate instead of dirty-pages-rate Chao Fan
2017-03-14 10:45 ` Daniel P. Berrange
2017-03-14 11:51   ` Chao Fan
2017-03-14 12:29 ` Juan Quintela
2017-03-14 12:37   ` Daniel P. Berrange
2017-03-14 13:20     ` Chao Fan
2017-03-15  4:13     ` Chao Fan
2017-03-15  9:42       ` Daniel P. Berrange [this message]
2017-03-14 13:33   ` Chao Fan
2017-03-14 14:54 ` Eric Blake
2017-03-14 15:40   ` Chao Fan

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=20170315094207.GD7770@redhat.com \
    --to=berrange@redhat.com \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=dgilbert@redhat.com \
    --cc=douly.fnst@cn.fujitsu.com \
    --cc=eblake@redhat.com \
    --cc=fanc.fnst@cn.fujitsu.com \
    --cc=lizhijian@cn.fujitsu.com \
    --cc=maozy.fnst@cn.fujitsu.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /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).