> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7da61ad..3ad8b10
> > 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -4523,6 +4523,52 @@ unsigned long get_max_pfn(void) }
> > EXPORT_SYMBOL(get_max_pfn);
> >
> > +static void mark_free_pages_bitmap(struct zone *zone, unsigned long
> start_pfn,
> > + unsigned long end_pfn, unsigned long *bitmap, unsigned long len) {
> > + unsigned long pfn, flags, page_num;
> > + unsigned int order, t;
> > + struct list_head *curr;
> > +
> > + if (zone_is_empty(zone))
> > + return;
> > + end_pfn = min(start_pfn + len, end_pfn);
> > + spin_lock_irqsave(&zone->lock, flags);
> > +
> > + for_each_migratetype_order(order, t) {
>
> Why not do each order separately? This way you can use a single bit to pass a
> huge page to host.
>
I thought about that before, and did not that because of complexity and small benefits.
Use separated page bitmaps for each order won't help to reduce the data traffic, except
ignoring the pages with small order.
> Not a requirement but hey.
>
> Alternatively (and maybe that is a better idea0 if you wanted to, you could
> just skip lone 4K pages.
> It's not clear that they are worth bothering with.
> Add a flag to start with some reasonably large order and go from there.
>
One of the main reason of this patch is to reduce the network traffic as much as possible,
it looks strange to skip the lone 4K pages. Skipping these pages can made live migration
faster? I think it depends on the amount of lone 4K pages.
In the other hand, it's faster to send one bit through virtio than that send 4K bytes
through even 10Gps network, is that true?
Liang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href