> 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 bits f
> On Fri, Dec 16, 2016 at 01:12:21AM +, 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.
>
> Not related to the balloon but
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 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
>
On Fri, Dec 16, 2016 at 01:12:21AM +, 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.
Not related to the balloon but how w
> 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".
> >
> > That will be much more simple. Right?
>
>
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".
>
> That will be much more simple. Right?
Sounds fine to m
> 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 address, that
> >>> should be
> >> enough in
> 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
> > >>
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 address, that should
>>> be
>> enough in the near f
> 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 (
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
> >>
> >> On 12/08/201
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
>>
>> On 12/08/2016 08:45 PM, Li, Liang Z wrote:
>>> What's the conclusion of your discus
> 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 decidi
> 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
> > > > statistic before deciding whether to ripping th
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
> > > statistic before deciding whether to ripping the bitmap from the ABI,
> > > am I right?
> >
> > I think
> 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 remove the
> bitmap, unless
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 remove the
bitmap, unless we have some d
> > 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
> >
> 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
On Wed, Dec 07, 2016 at 11:54:34AM -0800, Dave Hansen wrote:
> We're talking about a bunch of different stuff which is all being
> conflated. There are 3 issues here that I can see. I'll attempt to
> summarize what I think is going on:
>
> 1. Current patches do a hypercall for each order in the
We're talking about a bunch of different stuff which is all being
conflated. There are 3 issues here that I can see. I'll attempt to
summarize what I think is going on:
1. Current patches do a hypercall for each order in the allocator.
This is inefficient, but independent from the underlying
On Wed, Dec 07, 2016 at 10:44:31AM -0800, Dave Hansen wrote:
> On 12/07/2016 10:38 AM, Andrea Arcangeli wrote:
> >> > and leaves room for the bitmap size to be encoded as well, if we decide
> >> > we need a bitmap in the future.
> > How would a bitmap ever be useful with very large page-order?
>
>
On 12/07/2016 10:38 AM, Andrea Arcangeli wrote:
>> > and leaves room for the bitmap size to be encoded as well, if we decide
>> > we need a bitmap in the future.
> How would a bitmap ever be useful with very large page-order?
Please, guys. Read the patches. *Please*.
The current code doesn't ev
Hello,
On Wed, Dec 07, 2016 at 08:57:01AM -0800, Dave Hansen wrote:
> It is more space-efficient. We're fitting the order into 6 bits, which
> would allows the full 2^64 address space to be represented in one entry,
Very large order is the same as very large len, 6 bits of order or 8
bytes of le
Removing silly virtio-dev@ list because it's bouncing mail...
On 12/07/2016 08:21 AM, David Hildenbrand wrote:
>> Li's current patches do that. Well, maybe not pfn/length, but they do
>> take a pfn and page-order, which fits perfectly with the kernel's
>> concept of high-order pages.
>
> So we c
I did something similar. Filled the balloon with 15GB for a 16GB idle
guest, by
using bitmap, the madvise count was reduced to 605. when using the
PFNs, the madvise count
was 3932160. It means there are quite a lot consecutive bits in the
bitmap.
I didn't test for a guest with heavy memory worklo
On 12/07/2016 07:42 AM, David Hildenbrand wrote:
> Am 07.12.2016 um 14:35 schrieb Li, Liang Z:
>>> 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,
th
Am 07.12.2016 um 14:35 schrieb Li, Liang Z:
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
info
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
> 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 of
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 of the PFNs, to reduc
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 of the PFNs, to reduce the overhead of
virtio data transmission
32 matches
Mail list logo
