[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2] migration: skip sending ram pages released b

From: Jitendra Kolhe
Subject: Re: [Qemu-devel] [PATCH v2] migration: skip sending ram pages released by virtio-balloon driver.
Date: Fri, 29 Apr 2016 16:01:04 +0530
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

On 4/13/2016 5:06 PM, Michael S. Tsirkin wrote:
> On Wed, Apr 13, 2016 at 12:15:38PM +0100, Dr. David Alan Gilbert wrote:
>> * Michael S. Tsirkin (address@hidden) wrote:
>>> On Wed, Apr 13, 2016 at 04:24:55PM +0530, Jitendra Kolhe wrote:
>>>> Can we extend support for post-copy in a different patch set?
>>> If the optimization does not *help* on some paths,
>>> that's fine. The issue is with adding extra code
>>> special-casing protocols:
>>> +    if (migrate_postcopy_ram()) {
>>> +        balloon_bitmap_disable_state = BALLOON_BITMAP_DISABLE_PERMANENT;
>>> +    }
>>> Generally when one sees that patchset breaks XYZ...
>>> the easy solution is "check for XYZ
>>> and disable the optimization". But do this enough times
>>> and the codebase becomes impossible to reason about.
>>>     why did migration become slower? oh it enabled
>>>     optimization A and that conflicts with optimization B ...

Ok, I understand the confusion caused by such checks. Will remove 
the migration_postcopy checks from the patch and make sure things 
don’t break in postcopy path.

>> Hang on; this is getting all very complicated; I wouldn't start tieing
>> this thing up with postcopy yet.  Lets try and keep this simple for starters.
>> Dave
> Absolutely, but I don't understand why is this implemented in such
> a complex way.
> 1. keep track of pages in balloon in a bitmap
> 2. put bitmap in a ram block
> 3. check that before sending page. if there - it's a zero page

Thanks for the suggestion, putting bitmap in ramblock does remove the
code for migrating and dirty page tracking of balloon bitmap pages itself.
In case, the feature is turned-off, the balloon bitmap ramblock is resized
to 0 to make sure that the bitmap is not migrated to reduce the overhead.

> All the complexity is to avoid migrating an extra bit per page
> and it seems like a premature optimization to me at this stage.

Major benefit of the optimization is to avoid zero page scan for
ballooned out pages. Skipping migrating extra bit per ballooned out 
page is just an add-on benefit without any overhead as long as it 
doesn’t break any protocol. 

- Jitendra

>>>> and use 
>>>> current patch set to support other remaining protocols?
>>> Even disregarding postcopy, I think there were
>>> comments that need to be addressed.
>>> -- 
>>> MST
>> --
>> Dr. David Alan Gilbert / address@hidden / Manchester, UK

reply via email to

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