[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 4/5] ram: Use MigrationStats for statistics
From: |
Juan Quintela |
Subject: |
Re: [Qemu-devel] [PATCH 4/5] ram: Use MigrationStats for statistics |
Date: |
Tue, 06 Jun 2017 19:33:45 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Peter Xu <address@hidden> wrote:
> On Mon, Jun 05, 2017 at 01:34:45PM +0100, Dr. David Alan Gilbert wrote:
>> * Juan Quintela (address@hidden) wrote:
>> > RAM Statistics need to survive migration to make info migrate work, so we
>> > need to store them outside of RAMState. As we already have an struct
>> > with those fields, just used them. (MigrationStats and XBZRLECacheStats).
>> >
>> > Signed-off-by: Juan Quintela <address@hidden>
>>
>> Hmm OK; this feels very much like it's the opposite of 180f61f from
>> March; these variables keep moving around over the last couple of months
>> - are they going to stay still now?
>
> O:-)
>
> Meanwhile, I don't know whether it'll be necessary to remove all the
> functions like ram_bytes_transferred(), e.g., it would be just:
>
> uint64_t ram_bytes_transferred(void)
> {
> - return ram_state.bytes_transferred;
> + return ram_counters.transferred;
> }
>
> But I'm okay with either.
That value was only used for filling the statistics. And we are filling
a struct from another struct of the exact same type. Going through an
exported function looks stranger.
And as said in $commit, the idea was that creating a new counter was
easy, right now you have to:
- add it to MigrationParam (still have to do this)
- add it to MigrationParams (still have to do this)
- create the field in MigrationStats or RAMState
- create a function that exports it
- add that function in ram.h to export it
- add it on qmp_query (still have to do this)
So, we are moving from 6 steps to 3 steps. I think we are much better
now, no? O:-)
Later, Juan.
- [Qemu-devel] [PATCH 2/5] ram: Move ZERO_TARGET_PAGE inside XBZRLE, (continued)