[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] Output dirty-bytes-rate instead of dirty-pages-
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH] Output dirty-bytes-rate instead of dirty-pages-rate |
Date: |
Wed, 15 Mar 2017 09:42:07 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
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 <address@hidden> 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 <address@hidden>
> >> > Signed-off-by: Li Zhijian <address@hidden>
> >>
> >> 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/ :|