On Thu, Jun 11, 2015 at 10:27:05AM +0200, Michal Privoznik wrote:
On 11.06.2015 10:13, Daniel P. Berrange wrote:
On Wed, Jun 10, 2015 at 09:20:40PM +, Vivi L wrote:
Michal Privoznik mprivozn at redhat.com writes:
On 10.06.2015 01:05, Vivi L wrote:
Kashyap Chamarthy kchamart at
On 11.06.2015 10:48, Daniel P. Berrange wrote:
On Thu, Jun 11, 2015 at 10:27:05AM +0200, Michal Privoznik wrote:
On 11.06.2015 10:13, Daniel P. Berrange wrote:
On Wed, Jun 10, 2015 at 09:20:40PM +, Vivi L wrote:
Michal Privoznik mprivozn at redhat.com writes:
On 10.06.2015 01:05, Vivi L
On Thu, Jun 11, 2015 at 12:00 AM, Michal Privoznik mpriv...@redhat.com
wrote:
[please keep the list CC'ed]
On 10.06.2015 20:09, Clarylin L wrote:
Hi Michal,
Thanks a lot.
If 100 hugepages are pre-allocated, the guest can start without
decreasing
number of hugepages. Since the
Hi Michal,
I also tried the other option you mentioned The other option you have is
to not use guest NUMA nodes, in which case global -mem-path can be used.
by removing from xml
numatune
memory mode='strict' nodeset='0-1'/
/numatune
while keeping older qemu-1.5.3 which does not
With older qemu-1.5.3, I can start the guest by removing the following
lines from the xml config file and hugepages are correctly used.
numa
cell id='0' cpus='0-15' memory='67108864'/
cell id='1' cpus='16-31' memory='67108864'/
/numa
I believe these lines were used to
[please keep the list CC'ed]
On 10.06.2015 20:09, Clarylin L wrote:
Hi Michal,
Thanks a lot.
If 100 hugepages are pre-allocated, the guest can start without decreasing
number of hugepages. Since the guest requires 128 hugepages, it's kind of
expected that the guest would not take memory
On Wed, Jun 10, 2015 at 09:20:40PM +, Vivi L wrote:
Michal Privoznik mprivozn at redhat.com writes:
On 10.06.2015 01:05, Vivi L wrote:
Kashyap Chamarthy kchamart at redhat.com writes:
You might want re-test by explicitly setting the 'page' element and
'size' attribute?
On 11.06.2015 10:13, Daniel P. Berrange wrote:
On Wed, Jun 10, 2015 at 09:20:40PM +, Vivi L wrote:
Michal Privoznik mprivozn at redhat.com writes:
On 10.06.2015 01:05, Vivi L wrote:
Kashyap Chamarthy kchamart at redhat.com writes:
You might want re-test by explicitly setting the
On 10.06.2015 01:05, Vivi L wrote:
Kashyap Chamarthy kchamart at redhat.com writes:
You might want re-test by explicitly setting the 'page' element and
'size' attribute? From my test, I had something like this:
$ virsh dumpxml f21-vm | grep hugepages -B3 -A2
memory
Michal Privoznik mprivozn at redhat.com writes:
On 10.06.2015 01:05, Vivi L wrote:
Kashyap Chamarthy kchamart at redhat.com writes:
You might want re-test by explicitly setting the 'page' element and
'size' attribute? From my test, I had something like this:
$ virsh dumpxml
Configure hugepages and then start virtual guest via virsh start. However,
virtual guest failed to use hugepages although it's configured
The initial usage of system memory
[root@local ~]# free
totalusedfree shared buff/cache available
Mem: 263767352
On Tue, Jun 09, 2015 at 05:52:04AM +, Vivi L wrote:
Configure hugepages and then start virtual guest via virsh start. However,
virtual guest failed to use hugepages although it's configured
The initial usage of system memory
[root@local ~]# free
totalused
Kashyap Chamarthy kchamart at redhat.com writes:
You might want re-test by explicitly setting the 'page' element and
'size' attribute? From my test, I had something like this:
$ virsh dumpxml f21-vm | grep hugepages -B3 -A2
memory unit='KiB'2000896/memory
currentMemory
13 matches
Mail list logo
