On Mon, 2 Mar 2015, Mike Latimer wrote:
> On Monday, March 02, 2015 04:15:41 PM Stefano Stabellini wrote:
> > On Mon, 2 Mar 2015, Ian Campbell wrote:
> > > ? "Continue as long as progress is being made" is exactly what
> > > 2563bca1154 "libxl: Wait for ballooning if free memory is increasing"
> >
On Tue, 3 Mar 2015, Ian Campbell wrote:
> On Mon, 2015-03-02 at 15:49 -0700, Mike Latimer wrote:
> > On Monday, March 02, 2015 04:15:41 PM Stefano Stabellini wrote:
> > > On Mon, 2 Mar 2015, Ian Campbell wrote:
> > > > ? "Continue as long as progress is being made" is exactly what
> > > > 2563bca11
On Mon, 2015-03-02 at 15:49 -0700, Mike Latimer wrote:
> On Monday, March 02, 2015 04:15:41 PM Stefano Stabellini wrote:
> > On Mon, 2 Mar 2015, Ian Campbell wrote:
> > > ? "Continue as long as progress is being made" is exactly what
> > > 2563bca1154 "libxl: Wait for ballooning if free memory is i
On Monday, March 02, 2015 04:15:41 PM Stefano Stabellini wrote:
> On Mon, 2 Mar 2015, Ian Campbell wrote:
> > ? "Continue as long as progress is being made" is exactly what
> > 2563bca1154 "libxl: Wait for ballooning if free memory is increasing"
> > was trying to implement, so it certainly was the
On Monday, March 02, 2015 06:04:11 AM Jan Beulich wrote:
> > Of course users could just use dom0_mem and get down with it.
>
> I don't think we should make this a requirement for correct
> operation.
Exactly. I think from a best practices perspective, dom0_mem is still the
recommended approach.
On Mon, 2 Mar 2015, Ian Campbell wrote:
> On Mon, 2015-03-02 at 15:19 +, Stefano Stabellini wrote:
> > On Mon, 2 Mar 2015, Ian Campbell wrote:
> > > On Fri, 2015-02-27 at 17:31 -0700, Mike Latimer wrote:
> > > > On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
> > > > > On Friday, F
On Mon, 2015-03-02 at 15:19 +, Stefano Stabellini wrote:
> On Mon, 2 Mar 2015, Ian Campbell wrote:
> > On Fri, 2015-02-27 at 17:31 -0700, Mike Latimer wrote:
> > > On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
> > > > On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
>
On Mon, 2 Mar 2015, Ian Campbell wrote:
> On Fri, 2015-02-27 at 17:31 -0700, Mike Latimer wrote:
> > On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
> > > On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
> > > After adding 2048aeec, dom0's target is lowered by the required
>>> On 02.03.15 at 13:13, wrote:
> On Mon, 2 Mar 2015, Jan Beulich wrote:
>> >>> On 02.03.15 at 11:12, wrote:
>> > On Fri, 27 Feb 2015, Mike Latimer wrote:
>> >> On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
>> >> > On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
>> >>
On Mon, 2 Mar 2015, Jan Beulich wrote:
> >>> On 02.03.15 at 11:12, wrote:
> > On Fri, 27 Feb 2015, Mike Latimer wrote:
> >> On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
> >> > On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
> >> > After adding 2048aeec, dom0's target i
On Fri, 2015-02-27 at 17:31 -0700, Mike Latimer wrote:
> On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
> > On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
> > After adding 2048aeec, dom0's target is lowered by the required amount (e.g.
> > 64GB), but as dom0 cannot ballo
>>> On 02.03.15 at 11:12, wrote:
> On Fri, 27 Feb 2015, Mike Latimer wrote:
>> On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
>> > On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
>> > After adding 2048aeec, dom0's target is lowered by the required amount
> (e.g.
>> > 64
On Fri, 27 Feb 2015, Mike Latimer wrote:
> On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
> > On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
> > After adding 2048aeec, dom0's target is lowered by the required amount (e.g.
> > 64GB), but as dom0 cannot balloon down fast e
On Friday, February 27, 2015 11:29:12 AM Mike Latimer wrote:
> On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
> After adding 2048aeec, dom0's target is lowered by the required amount (e.g.
> 64GB), but as dom0 cannot balloon down fast enough,
> libxl_wait_for_memory_target returns -5,
On Friday, February 27, 2015 08:28:49 AM Mike Latimer wrote:
> On Friday, February 27, 2015 10:52:17 AM Stefano Stabellini wrote:
> > On Thu, 26 Feb 2015, Mike Latimer wrote:
> > >libxl_set_memory_target = 1
> >
> > The new memory target is set for dom0 successfully.
> >
> > >libxl_wait_f
On Friday, February 27, 2015 10:52:17 AM Stefano Stabellini wrote:
> On Thu, 26 Feb 2015, Mike Latimer wrote:
> >libxl_set_memory_target = 1
>
> The new memory target is set for dom0 successfully.
>
> >libxl_wait_for_free_memory = -5
>
> Still there isn't enough free memory in the system
On Fri, 27 Feb 2015, Ian Campbell wrote:
> On Thu, 2015-02-26 at 13:38 -0700, Mike Latimer wrote:
> > (Sorry for the delayed response, dealing with ENOTIME.)
> >
> > On Thursday, February 26, 2015 05:47:21 PM Ian Campbell wrote:
> > > On Thu, 2015-02-26 at 10:38 -0700, Mike Latimer wrote:
> > >
>
On Fri, 27 Feb 2015, Jan Beulich wrote:
> >>> On 26.02.15 at 18:53, wrote:
> > Or maybe we just need to change the libxl_set_memory_target call to use
> > an absolute memory target to avoid restricting dom0 memory more than
> > necessary at each iteration. Also increasing the timeout argument pass
On Thu, 26 Feb 2015, Mike Latimer wrote:
> On Thursday, February 26, 2015 01:45:16 PM Mike Latimer wrote:
> > On Thursday, February 26, 2015 05:53:06 PM Stefano Stabellini wrote:
> > > What is the return value of libxl_set_memory_target and
> > > libxl_wait_for_free_memory in that case? Isn't it ju
On Thu, 2015-02-26 at 16:30 -0700, Mike Latimer wrote:
> On Thursday, February 26, 2015 01:45:16 PM Mike Latimer wrote:
> > On Thursday, February 26, 2015 05:53:06 PM Stefano Stabellini wrote:
> > > What is the return value of libxl_set_memory_target and
> > > libxl_wait_for_free_memory in that cas
On Thu, 2015-02-26 at 13:38 -0700, Mike Latimer wrote:
> (Sorry for the delayed response, dealing with ENOTIME.)
>
> On Thursday, February 26, 2015 05:47:21 PM Ian Campbell wrote:
> > On Thu, 2015-02-26 at 10:38 -0700, Mike Latimer wrote:
> >
> > >rc = libxl_set_memory_target(ctx, 0, free_memk
>>> On 26.02.15 at 18:53, wrote:
> Or maybe we just need to change the libxl_set_memory_target call to use
> an absolute memory target to avoid restricting dom0 memory more than
> necessary at each iteration. Also increasing the timeout argument passed
> to the libxl_wait_for_free_memory call coul
On Thursday, February 26, 2015 01:45:16 PM Mike Latimer wrote:
> On Thursday, February 26, 2015 05:53:06 PM Stefano Stabellini wrote:
> > What is the return value of libxl_set_memory_target and
> > libxl_wait_for_free_memory in that case? Isn't it just a matter of
> > properly handle the return val
On Thursday, February 26, 2015 05:53:06 PM Stefano Stabellini wrote:
> What is the return value of libxl_set_memory_target and
> libxl_wait_for_free_memory in that case? Isn't it just a matter of
> properly handle the return values?
The return from libxl_set_memory_target is 0, as the assignment w
(Sorry for the delayed response, dealing with ENOTIME.)
On Thursday, February 26, 2015 05:47:21 PM Ian Campbell wrote:
> On Thu, 2015-02-26 at 10:38 -0700, Mike Latimer wrote:
>
> >rc = libxl_set_memory_target(ctx, 0, free_memkb - need_memkb, 1, 0);
>
> I think so. In essence we just need to u
On Thu, 26 Feb 2015, Mike Latimer wrote:
> On Thursday, February 26, 2015 03:57:54 PM Ian Campbell wrote:
> > On Thu, 2015-02-26 at 08:36 -0700, Mike Latimer wrote:
> > > There is still one aspect of my original patch that is important. As the
> > > code currently stands, the target for dom0 is set
On Thu, 2015-02-26 at 10:38 -0700, Mike Latimer wrote:
> On Thursday, February 26, 2015 03:57:54 PM Ian Campbell wrote:
> > On Thu, 2015-02-26 at 08:36 -0700, Mike Latimer wrote:
> > > There is still one aspect of my original patch that is important. As the
> > > code currently stands, the target f
On Thursday, February 26, 2015 03:57:54 PM Ian Campbell wrote:
> On Thu, 2015-02-26 at 08:36 -0700, Mike Latimer wrote:
> > There is still one aspect of my original patch that is important. As the
> > code currently stands, the target for dom0 is set lower during each
> > iteration of the loop. Unl
On Thu, 2015-02-26 at 08:36 -0700, Mike Latimer wrote:
> On Wednesday, February 25, 2015 02:09:50 PM Stefano Stabellini wrote:
> > > Is the upshot that Mike doesn't need to do anything further with his
> > > patch (i.e. can drop it)? I think so?
> >
> > Yes, I think so. Maybe he could help out tes
On Wednesday, February 25, 2015 02:09:50 PM Stefano Stabellini wrote:
> > Is the upshot that Mike doesn't need to do anything further with his
> > patch (i.e. can drop it)? I think so?
>
> Yes, I think so. Maybe he could help out testing the patches I am going
> to write :-)
Sorry for not respond
On Wed, 25 Feb 2015, Ian Campbell wrote:
> On Wed, 2015-02-25 at 12:00 +, Ian Campbell wrote:
> > On Wed, 2015-02-25 at 11:39 +, Stefano Stabellini wrote:
> > > On Tue, 24 Feb 2015, Ian Campbell wrote:
> > > > On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
> > > > > > Now that
On Wed, 2015-02-25 at 12:00 +, Ian Campbell wrote:
> On Wed, 2015-02-25 at 11:39 +, Stefano Stabellini wrote:
> > On Tue, 24 Feb 2015, Ian Campbell wrote:
> > > On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
> > > > > Now that we autodetect the use of dom0_mem and set autoball
On Wed, 2015-02-25 at 11:39 +, Stefano Stabellini wrote:
> On Tue, 24 Feb 2015, Ian Campbell wrote:
> > On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
> > > > Now that we autodetect the use of dom0_mem and set autoballooning
> > > > correctly perhaps we should just revert a39b5bc6
On Tue, 24 Feb 2015, Ian Campbell wrote:
> On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
> > > Now that we autodetect the use of dom0_mem and set autoballooning
> > > correctly perhaps we should just revert a39b5bc64?
> >
> > We could do that and theoretically it makes perfect sense
On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
> > Now that we autodetect the use of dom0_mem and set autoballooning
> > correctly perhaps we should just revert a39b5bc64?
>
> We could do that and theoretically it makes perfect sense, but it would
> result in an even bigger waste of
On Wed, 18 Feb 2015, Ian Campbell wrote:
> On Tue, 2015-02-10 at 14:34 -0700, Mike Latimer wrote:
> > On Monday, February 09, 2015 06:27:54 PM Mike Latimer wrote:
> > > While testing commit 2563bca1, I found that libxl_get_free_memory returns > > > 0
> > > until there is more free memory than requi
On Tue, 2015-02-10 at 14:34 -0700, Mike Latimer wrote:
> On Monday, February 09, 2015 06:27:54 PM Mike Latimer wrote:
> > While testing commit 2563bca1, I found that libxl_get_free_memory returns 0
> > until there is more free memory than required for freemem-slack. This means
> > that during the d
Hi Wei,
On Friday, February 13, 2015 11:13:50 AM Wei Liu wrote:
> On Tue, Feb 10, 2015 at 02:34:27PM -0700, Mike Latimer wrote:
> > On Monday, February 09, 2015 06:27:54 PM Mike Latimer wrote:
> > > It seems that there are two approaches to resolve this:
> > > - Introduce a hard limit on freemem-
On Tue, Feb 10, 2015 at 02:34:27PM -0700, Mike Latimer wrote:
> On Monday, February 09, 2015 06:27:54 PM Mike Latimer wrote:
> > While testing commit 2563bca1, I found that libxl_get_free_memory returns 0
> > until there is more free memory than required for freemem-slack. This means
> > that durin
On Monday, February 09, 2015 06:27:54 PM Mike Latimer wrote:
> While testing commit 2563bca1, I found that libxl_get_free_memory returns 0
> until there is more free memory than required for freemem-slack. This means
> that during the domain creation process, freed memory is first set aside for
> f
40 matches
Mail list logo
