search for: free_page_bitmap

...terrupts? Something else? > I assume you are familiar with the current virtio-balloon and how it works. The new interface is very simple, send a request to the virtio-balloon driver, The virtio-driver will travers the '&zone->free_area[order].free_list[t])' to construct a 'free_page_bitmap', and then the driver will send the content of 'free_page_bitmap' back to QEMU. That all the new interface does and there are no ' alloc_page' related affairs, so it's faster. Some code snippet: ---------------------------------------------- +static void mark_free_pages_b...

...terrupts? Something else? > I assume you are familiar with the current virtio-balloon and how it works. The new interface is very simple, send a request to the virtio-balloon driver, The virtio-driver will travers the '&zone->free_area[order].free_list[t])' to construct a 'free_page_bitmap', and then the driver will send the content of 'free_page_bitmap' back to QEMU. That all the new interface does and there are no ' alloc_page' related affairs, so it's faster. Some code snippet: ---------------------------------------------- +static void mark_free_pages_b...

...> > > I assume you are familiar with the current virtio-balloon and how it works. > The new interface is very simple, send a request to the virtio-balloon driver, > The virtio-driver will travers the '&zone->free_area[order].free_list[t])' to > construct a 'free_page_bitmap', and then the driver will send the content > of 'free_page_bitmap' back to QEMU. That all the new interface does and > there are no ' alloc_page' related affairs, so it's faster. > > > Some code snippet: > ----------------------------------------------...

> On Fri, Mar 04, 2016 at 09:12:12AM +0000, Li, Liang Z wrote: > > > Although I wonder which is cheaper; that would be fairly expensive > > > for the guest wouldn't it? And you'd somehow have to kick the guest > > > before migration to do the ballooning - and how long would you wait for > it to finish? > > > > About 5 seconds for an 8G guest,

> On Fri, Mar 04, 2016 at 09:12:12AM +0000, Li, Liang Z wrote: > > > Although I wonder which is cheaper; that would be fairly expensive > > > for the guest wouldn't it? And you'd somehow have to kick the guest > > > before migration to do the ballooning - and how long would you wait for > it to finish? > > > > About 5 seconds for an 8G guest,

The current QEMU live migration implementation mark the all the guest's RAM pages as dirtied in the ram bulk stage, all these pages will be processed and that takes quit a lot of CPU cycles. >From guest's point of view, it doesn't care about the content in free pages. We can make use of this fact and skip processing the free pages in the ram bulk stage, it can save a lot CPU cycles

The current QEMU live migration implementation mark the all the guest's RAM pages as dirtied in the ram bulk stage, all these pages will be processed and that takes quit a lot of CPU cycles. >From guest's point of view, it doesn't care about the content in free pages. We can make use of this fact and skip processing the free pages in the ram bulk stage, it can save a lot CPU cycles