qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 11/17] migration: Really use multiple pages a


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH v5 11/17] migration: Really use multiple pages at a time
Date: Wed, 09 Aug 2017 10:05:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Peter Xu <address@hidden> wrote:
> On Tue, Aug 08, 2017 at 06:06:04PM +0200, Juan Quintela wrote:
>> Peter Xu <address@hidden> wrote:
>> > On Mon, Jul 17, 2017 at 03:42:32PM +0200, Juan Quintela wrote:
>> >
>> > [...]
>> >
>> >>  static int multifd_send_page(uint8_t *address)
>> >>  {
>> >> -    int i;
>> >> +    int i, j;
>> >>      MultiFDSendParams *p = NULL; /* make happy gcc */
>> >> +    static multifd_pages_t pages;
>> >> +    static bool once;
>> >> +
>> >> +    if (!once) {
>> >> +        multifd_init_group(&pages);
>> >> +        once = true;
>> >
>> > Would it be good to put the "pages" into multifd_send_state? One is to
>> > stick globals together; another benefit is that we can remove the
>> > "once" here: we can then init the "pages" when init multifd_send_state
>> > struct (but maybe with a better name?...).
>> 
>> I did to be able to free it.
>
> Free it? But they a static variables, then how can we free them?
>
> (I thought the only way to free it is putting it into
>  multifd_send_state...)
>
> Something I must have missed here. :(

I did the change that you suggested in response to a comment from Dave
that asked where I freed it.   I see that my sentence was ambigous.

>
>> 
>> > (there are similar static variables in multifd_recv_page() as well, if
>> >  this one applies, then we can possibly use multifd_recv_state for
>> >  that one)
>> 
>> Also there.
>> 
>> >> +    }
>> >> +
>> >> +    pages.iov[pages.num].iov_base = address;
>> >> +    pages.iov[pages.num].iov_len = TARGET_PAGE_SIZE;
>> >> +    pages.num++;
>> >> +
>> >> +    if (pages.num < (pages.size - 1)) {
>> >> +        return UINT16_MAX;
>> >
>> > Nit: shall we define something for readability?  Like:
>> >
>> > #define  MULTIFD_FD_INVALID  UINT16_MAX
>> 
>> Also done.
>> 
>> MULTIFD_CONTINUE
>> 
>> But I am open to changes.
>
> It's clear enough at least to me. Thanks!

Thanks, Juan.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]