search for: virtio_balloon_f_chunk_transf

On Fri, Mar 03, 2017 at 01:40:27PM +0800, Wei Wang wrote: > From: Liang Li <liang.z.li at intel.com> > > Add a new feature bit, VIRTIO_BALLOON_F_CHUNK_TRANSFER. Please check > the implementation patch commit for details about this feature. better squash into next patch. > Signed-off-by: Liang Li <liang.z.li at intel.com> > Signed-off-by: Wei Wang <wei.w.wang at intel.com> > Cc: Michael S. Tsirkin <mst at redhat.com> >...

On Fri, Mar 03, 2017 at 01:40:27PM +0800, Wei Wang wrote: > From: Liang Li <liang.z.li at intel.com> > > Add a new feature bit, VIRTIO_BALLOON_F_CHUNK_TRANSFER. Please check > the implementation patch commit for details about this feature. better squash into next patch. > Signed-off-by: Liang Li <liang.z.li at intel.com> > Signed-off-by: Wei Wang <wei.w.wang at intel.com> > Cc: Michael S. Tsirkin <mst at redhat.com> >...

From: Liang Li <liang.z.li at intel.com> Add a new feature bit, VIRTIO_BALLOON_F_CHUNK_TRANSFER. Please check the implementation patch commit for details about this feature. Signed-off-by: Liang Li <liang.z.li at intel.com> Signed-off-by: Wei Wang <wei.w.wang at intel.com> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Paolo Bonzini <pbonzini at redhat.com> Cc: Corn...

...Size (52 bit) | Rsvd (12 bit) | -------------------------------------------------------- By doing so, step 4) can also be optimized by doing address translation and madvise() in chunks rather than page by page. This optimization requires the negotiation of a new feature bit, VIRTIO_BALLOON_F_CHUNK_TRANSFER. With this new feature, the above ballooning process takes ~590ms resulting in an improvement of ~85%. TODO: optimize stage 1) by allocating/freeing a chunk of pages instead of a single page each time. Signed-off-by: Liang Li <liang.z.li at intel.com> Signed-off-by: Wei Wang <wei.w.wa...

...--------------- | Size (64 bit) | ----------------------------------------------- By doing so, step 4) can also be optimized by doing address translation and madvise() in chunks rather than page by page. This optimization requires the negotation of a new feature bit, VIRTIO_BALLOON_F_CHUNK_TRANSFER. With this new feature, the above ballooning process takes ~590ms resulting in an improvement of ~85%. TODO: optimize stage 1) by allocating/freeing a chunk of pages instead of a single page each time. Signed-off-by: Liang Li <liang.z.li at intel.com> Signed-off-by: Wei Wang <wei.w.wa...

...-------------------------------------------------- > > > > By doing so, step 4) can also be optimized by doing address translation and > > madvise() in chunks rather than page by page. > > > > This optimization requires the negotiation of a new feature bit, > > VIRTIO_BALLOON_F_CHUNK_TRANSFER. > > > > With this new feature, the above ballooning process takes ~590ms resulting in > > an improvement of ~85%. > > > > TODO: optimize stage 1) by allocating/freeing a chunk of pages instead of a > > single page each time. > > > > Signed-off-b...

On 03/09/2017 10:14 PM, Matthew Wilcox wrote: > On Fri, Mar 03, 2017 at 01:40:28PM +0800, Wei Wang wrote: >> From: Liang Li <liang.z.li at intel.com> >> 1) allocating pages (6.5%) >> 2) sending PFNs to host (68.3%) >> 3) address translation (6.1%) >> 4) madvise (19%) >> >> This patch optimizes step 2) by transfering pages to the host in >>

On 03/11/2017 01:11 AM, Matthew Wilcox wrote: > On Fri, Mar 10, 2017 at 05:58:28PM +0200, Michael S. Tsirkin wrote: >> One of the issues of current balloon is the 4k page size >> assumption. For example if you free a huge page you >> have to split it up and pass 4k chunks to host. >> Quite often host can't free these 4k chunks at all (e.g. >> when it's

On 03/11/2017 10:10 PM, Matthew Wilcox wrote: > On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote: > > I'm thinking what if the guest needs to transfer these much physically > > continuous memory to host: 1GB+2MB+64KB+32KB+16KB+4KB. > > Is it going to use Six 64-bit chunks? Would it be simpler if we just > > use the 128-bit chunk format (we can drop the

On Fri, Mar 10, 2017 at 09:11:44AM -0800, Matthew Wilcox wrote: > On Fri, Mar 10, 2017 at 05:58:28PM +0200, Michael S. Tsirkin wrote: > > One of the issues of current balloon is the 4k page size > > assumption. For example if you free a huge page you > > have to split it up and pass 4k chunks to host. > > Quite often host can't free these 4k chunks at all (e.g. >

On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote: > I'm thinking what if the guest needs to transfer these much physically > continuous > memory to host: 1GB+2MB+64KB+32KB+16KB+4KB. > Is it going to use Six 64-bit chunks? Would it be simpler if we just > use the 128-bit chunk format (we can drop the previous normal 64-bit > format)? Is that a likely thing for the

On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote: > I'm thinking what if the guest needs to transfer these much physically > continuous > memory to host: 1GB+2MB+64KB+32KB+16KB+4KB. > Is it going to use Six 64-bit chunks? Would it be simpler if we just > use the 128-bit chunk format (we can drop the previous normal 64-bit > format)? Is that a likely thing for the

On Fri, Mar 10, 2017 at 01:25:41PM -0800, Matthew Wilcox wrote: > On Fri, Mar 10, 2017 at 09:35:21PM +0200, Michael S. Tsirkin wrote: > > > bit 0 clear => bits 1-11 encode a page count, bits 12-63 encode a PFN, page size 4k. > > > bit 0 set, bit 1 clear => bits 2-12 encode a page count, bits 13-63 encode a PFN, page size 8k > > > bits 0+1 set, bit 2 clear =>

On Sun, Mar 12, 2017 at 01:59:54AM +0000, Wang, Wei W wrote: > On 03/11/2017 10:10 PM, Matthew Wilcox wrote: > > On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote: > > > I'm thinking what if the guest needs to transfer these much physically > > > continuous memory to host: 1GB+2MB+64KB+32KB+16KB+4KB. > > > Is it going to use Six 64-bit chunks? Would

On Sun, Mar 12, 2017 at 01:59:54AM +0000, Wang, Wei W wrote: > On 03/11/2017 10:10 PM, Matthew Wilcox wrote: > > On Sat, Mar 11, 2017 at 07:59:31PM +0800, Wei Wang wrote: > > > I'm thinking what if the guest needs to transfer these much physically > > > continuous memory to host: 1GB+2MB+64KB+32KB+16KB+4KB. > > > Is it going to use Six 64-bit chunks? Would

On Fri, Mar 10, 2017 at 09:11:44AM -0800, Matthew Wilcox wrote: > On Fri, Mar 10, 2017 at 05:58:28PM +0200, Michael S. Tsirkin wrote: > > One of the issues of current balloon is the 4k page size > > assumption. For example if you free a huge page you > > have to split it up and pass 4k chunks to host. > > Quite often host can't free these 4k chunks at all (e.g. >

...------- > > > > > > By doing so, step 4) can also be optimized by doing address > > > translation and > > > madvise() in chunks rather than page by page. > > > > > > This optimization requires the negotiation of a new feature bit, > > > VIRTIO_BALLOON_F_CHUNK_TRANSFER. > > > > > > With this new feature, the above ballooning process takes ~590ms > > > resulting in an improvement of ~85%. > > > > > > TODO: optimize stage 1) by allocating/freeing a chunk of pages > > > instead of a single page each time. >...

...------- > > > > > > By doing so, step 4) can also be optimized by doing address > > > translation and > > > madvise() in chunks rather than page by page. > > > > > > This optimization requires the negotiation of a new feature bit, > > > VIRTIO_BALLOON_F_CHUNK_TRANSFER. > > > > > > With this new feature, the above ballooning process takes ~590ms > > > resulting in an improvement of ~85%. > > > > > > TODO: optimize stage 1) by allocating/freeing a chunk of pages > > > instead of a single page each time. >...

...| Rsvd (12 bit) | > -------------------------------------------------------- > > By doing so, step 4) can also be optimized by doing address translation and > madvise() in chunks rather than page by page. > > This optimization requires the negotiation of a new feature bit, > VIRTIO_BALLOON_F_CHUNK_TRANSFER. > > With this new feature, the above ballooning process takes ~590ms resulting in > an improvement of ~85%. > > TODO: optimize stage 1) by allocating/freeing a chunk of pages instead of a > single page each time. > > Signed-off-by: Liang Li <liang.z.li at intel.com&...

...| Rsvd (12 bit) | > -------------------------------------------------------- > > By doing so, step 4) can also be optimized by doing address translation and > madvise() in chunks rather than page by page. > > This optimization requires the negotiation of a new feature bit, > VIRTIO_BALLOON_F_CHUNK_TRANSFER. > > With this new feature, the above ballooning process takes ~590ms resulting in > an improvement of ~85%. > > TODO: optimize stage 1) by allocating/freeing a chunk of pages instead of a > single page each time. > > Signed-off-by: Liang Li <liang.z.li at intel.com&...