> Subject: Re: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating > & fast live migration > > On 12/07/2016 05:35 AM, Li, Liang Z wrote: > >> Am 30.11.2016 um 09:43 schrieb Liang Li: > >> IOW in real examples, do we have really large consecutive areas or > >> are all pages just completely distributed over our memory? > > > > The buddy system of Linux kernel memory management shows there > should > > be quite a lot of consecutive pages as long as there are a portion of > > free memory in the guest. > ... > > If all pages just completely distributed over our memory, it means the > > memory fragmentation is very serious, the kernel has the mechanism to > > avoid this happened. > > While it is correct that the kernel has anti-fragmentation mechanisms, I don't > think it invalidates the question as to whether a bitmap would be too sparse > to be effective. > > > In the other hand, the inflating should not happen at this time > > because the guest is almost 'out of memory'. > > I don't think this is correct. Most systems try to run with relatively little free > memory all the time, using the bulk of it as page cache. We have no reason > to expect that ballooning will only occur when there is lots of actual free > memory and that it will not occur when that same memory is in use as page > cache. > Yes. > In these patches, you're effectively still sending pfns. You're just sending > one pfn per high-order page which is giving a really nice speedup. IMNHO, > you're avoiding doing a real bitmap because creating a bitmap means either > have a really big bitmap, or you would have to do some sorting (or multiple > passes) of the free lists before populating a smaller bitmap. > > Like David, I would still like to see some data on whether the choice between > bitmaps and pfn lists is ever clearly in favor of bitmaps. You haven't > convinced me, at least, that the data isn't even worth collecting. I will try to get some data with the real workload and share it with your guys. Thanks! Liang -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
