RE: [PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process

> > > > +static void free_extended_page_bitmap(struct virtio_balloon *vb) { > > + int i, bmap_count = vb->nr_page_bmap; > > + > > + for (i = 1; i < bmap_count; i++) { > > + kfree(vb->page_bitmap[i]); > > + vb->page_bitmap[i] = NULL; > > + vb->nr_page_bmap--; > >

RE: [PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process

> > > > +static void free_extended_page_bitmap(struct virtio_balloon *vb) { > > + int i, bmap_count = vb->nr_page_bmap; > > + > > + for (i = 1; i < bmap_count; i++) { > > + kfree(vb->page_bitmap[i]); > > + vb->page_bitmap[i] = NULL; > > + vb->nr_page_bmap--; > >

RE: [PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process

> On Wed, Jan 18, 2017 at 04:56:58AM +0000, Li, Liang Z wrote: > > > > - virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL); > > > > - virtqueue_kick(vq); > > > > +static void do_set_resp_bitmap(struct virtio_balloon *vb, > > > >

RE: [PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process

> On Wed, Jan 18, 2017 at 04:56:58AM +0000, Li, Liang Z wrote: > > > > - virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL); > > > > - virtqueue_kick(vq); > > > > +static void do_set_resp_bitmap(struct virtio_balloon *vb, > > > >

RE: [virtio-dev] Re: [PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct

> > > > > > Signed-off-by: Liang Li > > > > > > Cc: Michael S. Tsirkin > > > > > > Cc: Paolo Bonzini > > > > > > Cc: Cornelia Huck > > > > > > Cc: Amit Shah > > > > > > Cc: Dave Hansen

RE: [virtio-dev] Re: [PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct

> > > > > > Signed-off-by: Liang Li > > > > > > Cc: Michael S. Tsirkin > > > > > > Cc: Paolo Bonzini > > > > > > Cc: Cornelia Huck > > > > > > Cc: Amit Shah > > > > > > Cc: Dave Hansen > > > > > > Cc: Andrea Arcangeli > > > > > > Cc: David Hildenbrand > > > > > > --- > > > > > >

RE: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Am 21.12.2016 um 07:52 schrieb Liang Li: > > This patch set contains two parts of changes to the virtio-balloon. > > > > One is the change for speeding up the inflating & deflating process, > > the main idea of this optimization is to use {pfn|length} to present > > the page information instead

RE: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Am 21.12.2016 um 07:52 schrieb Liang Li: > > This patch set contains two parts of changes to the virtio-balloon. > > > > One is the change for speeding up the inflating & deflating process, > > the main idea of this optimization is to use {pfn|length} to present > > the page information instead

RE: [PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process

> > - virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL); > > - virtqueue_kick(vq); > > +static void do_set_resp_bitmap(struct virtio_balloon *vb, > > + unsigned long base_pfn, int pages) > > > > - /* When host has read buffer, this completes via balloon_ack */ > > -

RE: [PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process

> > - virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL); > > - virtqueue_kick(vq); > > +static void do_set_resp_bitmap(struct virtio_balloon *vb, > > + unsigned long base_pfn, int pages) > > > > - /* When host has read buffer, this completes via balloon_ack */ > > -

RE: [virtio-dev] Re: [PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct

> Sent: Wednesday, January 18, 2017 3:11 AM > To: Li, Liang Z > Cc: k...@vger.kernel.org; virtio-...@lists.oasis-open.org; qemu- > de...@nongnu.org; linux...@kvack.org; linux-kernel@vger.kernel.org; > virtualizat...@lists.linux-foundation.org; amit.s...@redhat.com; Hansen, >

RE: [virtio-dev] Re: [PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct

> Sent: Wednesday, January 18, 2017 3:11 AM > To: Li, Liang Z > Cc: k...@vger.kernel.org; virtio-...@lists.oasis-open.org; qemu- > de...@nongnu.org; linux...@kvack.org; linux-kernel@vger.kernel.org; > virtualizat...@lists.linux-foundation.org; amit.s...@redhat.com; Hansen, >

RE: [PATCH RFC 0/4] 5-level EPT

> On 29/12/2016 10:25, Liang Li wrote: > > x86-64 is currently limited physical address width to 46 bits, which > > can support 64 TiB of memory. Some vendors require to support more for > > some use case. Intel plans to extend the physical address width to > > 52 bits in some of the future

RE: [PATCH RFC 0/4] 5-level EPT

> On 29/12/2016 10:25, Liang Li wrote: > > x86-64 is currently limited physical address width to 46 bits, which > > can support 64 TiB of memory. Some vendors require to support more for > > some use case. Intel plans to extend the physical address width to > > 52 bits in some of the future

RE: [virtio-dev] Re: [PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct

> On Wed, Dec 21, 2016 at 02:52:25PM +0800, Liang Li wrote: > > Add a new feature which supports sending the page information with > > range array. The current implementation uses PFNs array, which is not > > very efficient. Using ranges can improve the performance of > > inflating/deflating

RE: [virtio-dev] Re: [PATCH v6 kernel 2/5] virtio-balloon: define new feature bit and head struct

> On Wed, Dec 21, 2016 at 02:52:25PM +0800, Liang Li wrote: > > Add a new feature which supports sending the page information with > > range array. The current implementation uses PFNs array, which is not > > very efficient. Using ranges can improve the performance of > > inflating/deflating

RE: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

Hi guys, Could you help to review this patch set? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Wednesday, December 21, 2016 2:52 PM > To: k...@vger.kernel.org > Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongnu.org; linux- > m...@kvack

RE: [PATCH v6 kernel 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

Hi guys, Could you help to review this patch set? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Wednesday, December 21, 2016 2:52 PM > To: k...@vger.kernel.org > Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongnu.org; linux- > m...@kvack

RE: [PATCH RFC 0/4] 5-level EPT

> Subject: Re: [PATCH RFC 0/4] 5-level EPT > > On Thu, 29 Dec 2016 17:25:59 +0800, Liang Li said: > > x86-64 is currently limited physical address width to 46 bits, which > > can support 64 TiB of memory. Some vendors require to support more for > > some use case. Intel plans to extend the

RE: [PATCH RFC 0/4] 5-level EPT

> Subject: Re: [PATCH RFC 0/4] 5-level EPT > > On Thu, 29 Dec 2016 17:25:59 +0800, Liang Li said: > > x86-64 is currently limited physical address width to 46 bits, which > > can support 64 TiB of memory. Some vendors require to support more for > > some use case. Intel plans to extend the

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On Thu, Dec 15, 2016 at 05:40:45PM -0800, Dave Hansen wrote: > > On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > > > Use 52 bi

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On Thu, Dec 15, 2016 at 05:40:45PM -0800, Dave Hansen wrote: > > On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > > > Use 52 bi

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On Fri, Dec 16, 2016 at 01:12:21AM +0000, Li, Liang Z wrote: > > There still exist the case if the MAX_ORDER is configured to a large > > value, e.g. 36 for a system with huge amount of memory, then there is only > 28 bits left for the pfn, which is not enough. > > No

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On Fri, Dec 16, 2016 at 01:12:21AM +0000, Li, Liang Z wrote: > > There still exist the case if the MAX_ORDER is configured to a large > > value, e.g. 36 for a system with huge amount of memory, then there is only > 28 bits left for the pfn, which is not enough. > > No

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > Use 52 bits for 'pfn', 12 bits for 'length', when the 12 bits is not long > > enough > for the 'length' > > Set the 'length' to a special value to indicate the "actual length in next 8 > bytes". &

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 12/15/2016 05:38 PM, Li, Liang Z wrote: > > > > Use 52 bits for 'pfn', 12 bits for 'length', when the 12 bits is not long > > enough > for the 'length' > > Set the 'length' to a special value to indicate the "actual length in next 8 > bytes". &

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 12/15/2016 04:48 PM, Li, Liang Z wrote: > >>> It seems we leave too many bit for the pfn, and the bits leave for > >>> length is not enough, How about keep 45 bits for the pfn and 19 bits > >>> for length, 45 bits for pfn can cover 57 bits physical ad

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 12/15/2016 04:48 PM, Li, Liang Z wrote: > >>> It seems we leave too many bit for the pfn, and the bits leave for > >>> length is not enough, How about keep 45 bits for the pfn and 19 bits > >>> for length, 45 bits for pfn can cover 57 bits physical ad

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On Thu, Dec 15, 2016 at 07:34:33AM -0800, Dave Hansen wrote: > > On 12/14/2016 12:59 AM, Li, Liang Z wrote: > > >> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend > > >> virtio-balloon for fast (de)inflating & fast live migration > > >>

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On Thu, Dec 15, 2016 at 07:34:33AM -0800, Dave Hansen wrote: > > On 12/14/2016 12:59 AM, Li, Liang Z wrote: > > >> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend > > >> virtio-balloon for fast (de)inflating & fast live migration > > >>

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On 12/14/2016 12:59 AM, Li, Liang Z wrote: > >> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon > >> for fast (

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On 12/14/2016 12:59 AM, Li, Liang Z wrote: > >> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon > >> for fast (

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding wh

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding wh

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> fast (de)inflating & fast live migration > > Hello, > > On Fri, Dec 09, 2016 at 05:35:45AM +, Li, Liang Z wrote: > > > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > > > What's the conclusion of your discussion? It seems you want some > > >

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> fast (de)inflating & fast live migration > > Hello, > > On Fri, Dec 09, 2016 at 05:35:45AM +, Li, Liang Z wrote: > > > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > > > What's the conclusion of your discussion? It seems you want some > > >

RE: [RFC PATCH 0/4] KVM: Emulate UMIP (or almost do so)

> UMIP (User-Mode Instruction Prevention) is a feature of future Intel > processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT and SMSW from > user-mode processes. > > The idea here is to use virtualization intercepts to emulate UMIP; it slows > down the instructions when they're executed in

RE: [RFC PATCH 0/4] KVM: Emulate UMIP (or almost do so)

> UMIP (User-Mode Instruction Prevention) is a feature of future Intel > processors (Cannonlake?) that blocks SLDT, SGDT, STR, SIDT and SMSW from > user-mode processes. > > The idea here is to use virtualization intercepts to emulate UMIP; it slows > down the instructions when they're executed in

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding whether to ripping the bitmap from the ABI, > > am I right? > > I think Andrea and David feel pretty strongly that we should

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding whether to ripping the bitmap from the ABI, > > am I right? > > I think Andrea and David feel pretty strongly that we should

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> > 1. Current patches do a hypercall for each order in the allocator. > >This is inefficient, but independent from the underlying data > >structure in the ABI, unless bitmaps are in play, which they aren't. > > 2. Should we have bitmaps in the ABI, even if they are not in use by the > >

RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> > 1. Current patches do a hypercall for each order in the allocator. > >This is inefficient, but independent from the underlying data > >structure in the ABI, unless bitmaps are in play, which they aren't. > > 2. Should we have bitmaps in the ABI, even if they are not in use by the > >

RE: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> 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 consecu

RE: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> 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 consecu

RE: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Am 30.11.2016 um 09:43 schrieb Liang Li: > > This patch set contains two parts of changes to the virtio-balloon. > > > > One is the change for speeding up the inflating & deflating process, > > the main idea of this optimization is to use bitmap to send the page > > information to host instead

RE: [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration

> Am 30.11.2016 um 09:43 schrieb Liang Li: > > This patch set contains two parts of changes to the virtio-balloon. > > > > One is the change for speeding up the inflating & deflating process, > > the main idea of this optimization is to use bitmap to send the page > > information to host instead

RE: [PATCH kernel v5 5/5] virtio-balloon: tell host vm's unused page info

> >>> + mutex_lock(>balloon_lock); > >>> + > >>> + for (order = MAX_ORDER - 1; order >= 0; order--) { > >> > >> I scratched my head for a bit on this one. Why are you walking over > >> orders, > >> *then* zones. I *think* you're doing it because you can efficiently > >> fill the bitmaps at a

RE: [PATCH kernel v5 5/5] virtio-balloon: tell host vm's unused page info

> >>> + mutex_lock(>balloon_lock); > >>> + > >>> + for (order = MAX_ORDER - 1; order >= 0; order--) { > >> > >> I scratched my head for a bit on this one. Why are you walking over > >> orders, > >> *then* zones. I *think* you're doing it because you can efficiently > >> fill the bitmaps at a

RE: [PATCH kernel v5 5/5] virtio-balloon: tell host vm's unused page info

> On 11/30/2016 12:43 AM, Liang Li wrote: > > +static void send_unused_pages_info(struct virtio_balloon *vb, > > + unsigned long req_id) > > +{ > > + struct scatterlist sg_in; > > + unsigned long pos = 0; > > + struct virtqueue *vq = vb->req_vq; > > + struct

RE: [PATCH kernel v5 5/5] virtio-balloon: tell host vm's unused page info

> On 11/30/2016 12:43 AM, Liang Li wrote: > > +static void send_unused_pages_info(struct virtio_balloon *vb, > > + unsigned long req_id) > > +{ > > + struct scatterlist sg_in; > > + unsigned long pos = 0; > > + struct virtqueue *vq = vb->req_vq; > > + struct

RE: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info

> On 11/06/2016 07:37 PM, Li, Liang Z wrote: > >> Let's say we do a 32k bitmap that can hold ~1M pages. That's 4GB of RAM. > >> On a 1TB system, that's 256 passes through the top-level loop. > >> The bottom-level lists have tens of thousands of pages in them, even

RE: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info

> On 11/06/2016 07:37 PM, Li, Liang Z wrote: > >> Let's say we do a 32k bitmap that can hold ~1M pages. That's 4GB of RAM. > >> On a 1TB system, that's 256 passes through the top-level loop. > >> The bottom-level lists have tens of thousands of pages in them, even

RE: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info

> Please squish this and patch 5 together. It makes no sense to separate them. > OK. > > +static void send_unused_pages_info(struct virtio_balloon *vb, > > + unsigned long req_id) > > +{ > > + struct scatterlist sg_in; > > + unsigned long pfn = 0, bmap_len,

RE: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info

> Please squish this and patch 5 together. It makes no sense to separate them. > OK. > > +static void send_unused_pages_info(struct virtio_balloon *vb, > > + unsigned long req_id) > > +{ > > + struct scatterlist sg_in; > > + unsigned long pfn = 0, bmap_len,

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 10/26/2016 03:06 AM, Li, Liang Z wrote: > > I am working on Dave's new bitmap schema, I have finished the part of > > getting the 'hybrid scheme bitmap' and found the complexity was more > > than I expected. The main issue is more memory is required to save the >

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 10/26/2016 03:06 AM, Li, Liang Z wrote: > > I am working on Dave's new bitmap schema, I have finished the part of > > getting the 'hybrid scheme bitmap' and found the complexity was more > > than I expected. The main issue is more memory is required to save the >

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

.@redhat.com > Subject: Re: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast > (de)inflating & fast live migration > > On 10/26/2016 03:13 AM, Li, Liang Z wrote: > > 3 times memory required is not accurate, please ignore this. sorry ... > > The complexity is the

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

.@redhat.com > Subject: Re: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast > (de)inflating & fast live migration > > On 10/26/2016 03:13 AM, Li, Liang Z wrote: > > 3 times memory required is not accurate, please ignore this. sorry ... > > The complexity is the

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> > On 10/20/2016 11:24 PM, Liang Li wrote: > > > Dave Hansen suggested a new scheme to encode the data structure, > > > because of additional complexity, it's not implemented in v3. > > > > So, what do you want done with this patch set? Do you want it applied > > as-is so that we can introduce a

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> > On 10/20/2016 11:24 PM, Liang Li wrote: > > > Dave Hansen suggested a new scheme to encode the data structure, > > > because of additional complexity, it's not implemented in v3. > > > > So, what do you want done with this patch set? Do you want it applied > > as-is so that we can introduce a

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Dave Hansen suggested a new scheme to encode the data structure, > > because of additional complexity, it's not implemented in v3. > > So, what do you want done with this patch set? Do you want it applied as-is > so that we can introduce a new

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Dave Hansen suggested a new scheme to encode the data structure, > > because of additional complexity, it's not implemented in v3. > > So, what do you want done with this patch set? Do you want it applied as-is > so that we can introduce a new

RE: [RESEND PATCH v3 kernel 4/7] virtio-balloon: speed up inflate/deflate process

> > +static inline void init_pfn_range(struct virtio_balloon *vb) { > > + vb->min_pfn = ULONG_MAX; > > + vb->max_pfn = 0; > > +} > > + > > +static inline void update_pfn_range(struct virtio_balloon *vb, > > +struct page *page) > > +{ > > + unsigned long

RE: [RESEND PATCH v3 kernel 4/7] virtio-balloon: speed up inflate/deflate process

> > +static inline void init_pfn_range(struct virtio_balloon *vb) { > > + vb->min_pfn = ULONG_MAX; > > + vb->max_pfn = 0; > > +} > > + > > +static inline void update_pfn_range(struct virtio_balloon *vb, > > +struct page *page) > > +{ > > + unsigned long

RE: [RESEND PATCH v3 kernel 3/7] mm: add a function to get the max pfn

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Expose the function to get the max pfn, so it can be used in the > > virtio-balloon device driver. Simply include the 'linux/bootmem.h' > > is not enough, if the device driver is built to a module, directly > > refer the max_pfn lead to build failed. >

RE: [RESEND PATCH v3 kernel 3/7] mm: add a function to get the max pfn

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Expose the function to get the max pfn, so it can be used in the > > virtio-balloon device driver. Simply include the 'linux/bootmem.h' > > is not enough, if the device driver is built to a module, directly > > refer the max_pfn lead to build failed. >

RE: [RESEND PATCH v3 kernel 2/7] virtio-balloon: define new feature bit and page bitmap head

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Add a new feature which supports sending the page information with a > > bitmap. The current implementation uses PFNs array, which is not very > > efficient. Using bitmap can improve the performance of > > inflating/deflating significantly > > Why is

RE: [RESEND PATCH v3 kernel 2/7] virtio-balloon: define new feature bit and page bitmap head

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Add a new feature which supports sending the page information with a > > bitmap. The current implementation uses PFNs array, which is not very > > efficient. Using bitmap can improve the performance of > > inflating/deflating significantly > > Why is

RE: [RESEND PATCH v3 kernel 1/7] virtio-balloon: rework deflate to add page to a list

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Will allow faster notifications using a bitmap down the road. > > balloon_pfn_to_page() can be removed because it's useless. > > This is a pretty terse description of what's going on here. Could you try to > elaborate a bit? What *is* the current

RE: [RESEND PATCH v3 kernel 1/7] virtio-balloon: rework deflate to add page to a list

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Will allow faster notifications using a bitmap down the road. > > balloon_pfn_to_page() can be removed because it's useless. > > This is a pretty terse description of what's going on here. Could you try to > elaborate a bit? What *is* the current

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> On Fri, Oct 21, 2016 at 10:25:21AM -0700, Dave Hansen wrote: > > On 10/20/2016 11:24 PM, Liang Li wrote: > > > Dave Hansen suggested a new scheme to encode the data structure, > > > because of additional complexity, it's not implemented in v3. > > > > So, what do you want done with this patch

RE: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> On Fri, Oct 21, 2016 at 10:25:21AM -0700, Dave Hansen wrote: > > On 10/20/2016 11:24 PM, Liang Li wrote: > > > Dave Hansen suggested a new scheme to encode the data structure, > > > because of additional complexity, it's not implemented in v3. > > > > So, what do you want done with this patch

RE: [PATCH v2 1/5] mmu: extend the is_present check to 32 bits

Intel SDM doesn't describe whether the A bit will be set or not when CPU accesses a no present EPT page table entry? even this patch works for the current CPU, it's not good to make such an assumption. Should we revert it? Thanks! Liang > -Original Message- > From:

RE: [PATCH v2 1/5] mmu: extend the is_present check to 32 bits

Intel SDM doesn't describe whether the A bit will be set or not when CPU accesses a no present EPT page table entry? even this patch works for the current CPU, it's not good to make such an assumption. Should we revert it? Thanks! Liang > -Original Message- > From:

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast > (de)inflating > & fast live migration > > 2016-08-08 14:35 GMT+08:00 Liang Li : > > This patch set contains two parts of changes to the virtio-balloon. > > > > One is the change for speeding up the

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast > (de)inflating > & fast live migration > > 2016-08-08 14:35 GMT+08:00 Liang Li : > > This patch set contains two parts of changes to the virtio-balloon. > > > > One is the change for speeding up the inflating & deflating

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

Hi Michael, I know you are very busy. If you have time, could you help to take a look at this patch set? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Thursday, August 18, 2016 9:06 AM > To: Michael S. Tsirkin > Cc: virtualizat...@lists.linux-founda

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

Hi Michael, I know you are very busy. If you have time, could you help to take a look at this patch set? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Thursday, August 18, 2016 9:06 AM > To: Michael S. Tsirkin > Cc: virtualizat...@lists.linux-founda

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

Hi Michael, Could you help to review this version when you have time? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Monday, August 08, 2016 2:35 PM > To: linux-kernel@vger.kernel.org > Cc: virtualizat...@lists.linux-foundation.org; linux...@kvack.o

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

Hi Michael, Could you help to review this version when you have time? Thanks! Liang > -Original Message- > From: Li, Liang Z > Sent: Monday, August 08, 2016 2:35 PM > To: linux-kernel@vger.kernel.org > Cc: virtualizat...@lists.linux-foundation.org; linux...@kvack.o

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast > (de)inflating > & fast live migration > > On 08/07/2016 11:35 PM, Liang Li wrote: > > Dave Hansen suggested a new scheme to encode the data structure, > > because of additional complexity, it's not implemented in v3. > >

RE: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast > (de)inflating > & fast live migration > > On 08/07/2016 11:35 PM, Liang Li wrote: > > Dave Hansen suggested a new scheme to encode the data structure, > > because of additional complexity, it's not implemented in v3. > >

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > It's only small because it makes you rescan the free list. > > So maybe you should do something else. > > I looked at it a bit. Instead of scanning the free list, how about > > scanning actual page structures? If page is unused, pass it to host. > > Solves the problem of rescanning multiple

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > It's only small because it makes you rescan the free list. > > So maybe you should do something else. > > I looked at it a bit. Instead of scanning the free list, how about > > scanning actual page structures? If page is unused, pass it to host. > > Solves the problem of rescanning multiple

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT; > > > > > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn()); > > > > > + vb->bmap_len = ALIGN(vb->pfn_limit,

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT; > > > > > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn()); > > > > > + vb->bmap_len = ALIGN(vb->pfn_limit,

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> On Thu, Jul 28, 2016 at 06:36:18AM +0000, Li, Liang Z wrote: > > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > > > > How big was the pfn buffer before? > > > > > > > > Yes, it is if the max pfn is more than 3

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> On Thu, Jul 28, 2016 at 06:36:18AM +0000, Li, Liang Z wrote: > > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > > > > How big was the pfn buffer before? > > > > > > > > Yes, it is if the max pfn is more than 3

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> On Thu, Jul 28, 2016 at 03:06:37AM +0000, Li, Liang Z wrote: > > > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page > > > > +bitmap > > > > + * to prevent a very large page bitmap, there are two reasons for this: > > > > + *

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> On Thu, Jul 28, 2016 at 03:06:37AM +0000, Li, Liang Z wrote: > > > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page > > > > +bitmap > > > > + * to prevent a very large page bitmap, there are two reasons for this: > > > > + *

RE: [PATCH v2 repost 7/7] virtio-balloon: tell host vm's free page info

> > } > > > > +static void update_free_pages_stats(struct virtio_balloon *vb, > > why _stats? Will change. > > + max_pfn = get_max_pfn(); > > + mutex_lock(>balloon_lock); > > + while (pfn < max_pfn) { > > + memset(vb->page_bitmap, 0, vb->bmap_len); > > + ret =

RE: [PATCH v2 repost 7/7] virtio-balloon: tell host vm's free page info

> > } > > > > +static void update_free_pages_stats(struct virtio_balloon *vb, > > why _stats? Will change. > > + max_pfn = get_max_pfn(); > > + mutex_lock(>balloon_lock); > > + while (pfn < max_pfn) { > > + memset(vb->page_bitmap, 0, vb->bmap_len); > > + ret =

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > > How big was the pfn buffer before? > > > > Yes, it is if the max pfn is more than 32GB. > > The size of the pfn buffer use before is 256*4 = 1024 Bytes, it's too > > small, and it's the main reason for bad performance.

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > > How big was the pfn buffer before? > > > > Yes, it is if the max pfn is more than 32GB. > > The size of the pfn buffer use before is 256*4 = 1024 Bytes, it's too > > small, and it's the main reason for bad performance.

RE: [virtio-dev] Re: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

> > 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,

RE: [virtio-dev] Re: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

> > 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,

RE: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

> On 07/27/2016 03:05 PM, Michael S. Tsirkin wrote: > > On Wed, Jul 27, 2016 at 09:40:56AM -0700, Dave Hansen wrote: > >> On 07/26/2016 06:23 PM, Liang Li wrote: > >>> + for_each_migratetype_order(order, t) { > >>> + list_for_each(curr, >free_area[order].free_list[t]) { > >>> +

RE: [PATCH v2 repost 6/7] mm: add the related functions to get free page info

> On 07/27/2016 03:05 PM, Michael S. Tsirkin wrote: > > On Wed, Jul 27, 2016 at 09:40:56AM -0700, Dave Hansen wrote: > >> On 07/26/2016 06:23 PM, Liang Li wrote: > >>> + for_each_migratetype_order(order, t) { > >>> + list_for_each(curr, >free_area[order].free_list[t]) { > >>> +

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > +/* > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap > > + * to prevent a very large page bitmap, there are two reasons for this: > > + * 1) to save memory. > > + * 2) allocate a large bitmap may fail. > > + * > > + * The actual limit of pfn is determined by: > > + *

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > +/* > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page bitmap > > + * to prevent a very large page bitmap, there are two reasons for this: > > + * 1) to save memory. > > + * 2) allocate a large bitmap may fail. > > + * > > + * The actual limit of pfn is determined by: > > + *

  1   2   3   >