Il 09/04/2014 17:12, Daniel P. Berrange ha scritto:
On Tue, Apr 08, 2014 at 03:06:13PM -0300, Marcelo Tosatti wrote:
On Mon, Mar 17, 2014 at 09:39:54AM +, Daniel P. Berrange wrote:
We recently had a bunch more feature requests around huge page support
in libvirt, so I think it is
On Mon, Mar 17, 2014 at 09:39:54AM +, Daniel P. Berrange wrote:
On Fri, Mar 14, 2014 at 06:52:19PM -0300, Marcelo Tosatti wrote:
On Tue, Feb 04, 2014 at 11:54:22AM -0500, Marcelo Tosatti wrote:
On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014
On Tue, Apr 08, 2014 at 03:06:13PM -0300, Marcelo Tosatti wrote:
On Mon, Mar 17, 2014 at 09:39:54AM +, Daniel P. Berrange wrote:
We recently had a bunch more feature requests around huge page support
in libvirt, so I think it is preferrable not to merge this currently.
We need to
On Fri, Mar 14, 2014 at 06:52:19PM -0300, Marcelo Tosatti wrote:
On Tue, Feb 04, 2014 at 11:54:22AM -0500, Marcelo Tosatti wrote:
On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote:
Add an element named
On Tue, Feb 04, 2014 at 11:54:22AM -0500, Marcelo Tosatti wrote:
On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote:
Add an element named strict-hugepages to control whether to
refuse guest
On Fri, Mar 14, 2014 at 06:52:19PM -0300, Marcelo Tosatti wrote:
On Tue, Feb 04, 2014 at 11:54:22AM -0500, Marcelo Tosatti wrote:
On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote:
Add an element named
On Tue, Feb 04, 2014 at 03:04:11PM -0700, Eric Blake wrote:
On 02/04/2014 02:57 PM, Marcelo Tosatti wrote:
So perhaps we do need some policy attribute on the hugepages/
element to indicate desired behaviour here.
What about the following new element under hugepages/ ?
On Wed, Feb 05, 2014 at 09:49:53AM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 03:04:11PM -0700, Eric Blake wrote:
On 02/04/2014 02:57 PM, Marcelo Tosatti wrote:
So perhaps we do need some policy attribute on the hugepages/
element to indicate desired behaviour here.
On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote:
Add an element named strict-hugepages to control whether to
refuse guest initialization in case hugepage allocation cannot
be performed.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git
On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote:
Add an element named strict-hugepages to control whether to
refuse guest initialization in case hugepage allocation cannot
be performed.
On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote:
Add an element named strict-hugepages to control whether to
refuse guest initialization in case hugepage allocation cannot
be performed.
On Tue, Feb 04, 2014 at 11:54:22AM -0500, Marcelo Tosatti wrote:
On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote:
Add an element named strict-hugepages to control whether to
refuse guest
On Tue, Feb 04, 2014 at 12:18:34PM -0500, Marcelo Tosatti wrote:
On Tue, Feb 04, 2014 at 05:10:13PM +, Daniel P. Berrange wrote:
Because there is no guarantee with -mem-prealloc. For instance, if the
hugepage path is not actually hugetlbfs backed, QEMU falls back to
malloc().
You're OK with StrictHugePageSize=N element ?
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Feb 04, 2014 at 05:10:13PM +, Daniel P. Berrange wrote:
Because there is no guarantee with -mem-prealloc. For instance, if the
hugepage path is not actually hugetlbfs backed, QEMU falls back to
malloc().
Well if you can't fix -mem-prealloc to properly report errors for reasons
On Tue, Feb 04, 2014 at 12:22:00PM -0500, Marcelo Tosatti wrote:
You're OK with StrictHugePageSize=N element ?
I'm not entirely sure what that would do ? Is that for when people want
to have a specific size of hugepages ? If so, then I guess we might
actually need some kind of granularity
On Tue, Feb 04, 2014 at 05:26:31PM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 12:22:00PM -0500, Marcelo Tosatti wrote:
You're OK with StrictHugePageSize=N element ?
I'm not entirely sure what that would do ? Is that for when people want
to have a specific size of hugepages
On Tue, Feb 04, 2014 at 05:26:31PM +, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 12:22:00PM -0500, Marcelo Tosatti wrote:
You're OK with StrictHugePageSize=N element ?
I'm not entirely sure what that would do ? Is that for when people want
to have a specific size of hugepages
On 02/04/2014 02:57 PM, Marcelo Tosatti wrote:
So perhaps we do need some policy attribute on the hugepages/
element to indicate desired behaviour here.
What about the following new element under hugepages/ ?
enforce_hugepage_size=integer
Which feels a bit redundant (we're already
On Tue, Feb 04, 2014 at 03:04:11PM -0700, Eric Blake wrote:
On 02/04/2014 02:57 PM, Marcelo Tosatti wrote:
So perhaps we do need some policy attribute on the hugepages/
element to indicate desired behaviour here.
What about the following new element under hugepages/ ?
On 02/04/2014 07:42 PM, Marcelo Tosatti wrote:
hugepages
size strict='yes' unit='G'1/size
/hugepages
where strict could be no if we are giving a hint but don't care if the
hint cannot be honored (default yes if omitted), and where unit + value
Its awkward because you'd always want the
21 matches
Mail list logo
