add kvm hugepage variant and test

KVM_AUTOTEST Lukáš Doktor 4 participants 13 messages Jul 9, 2009 – Jul 27, 2009 KVM

Share & tools

Lukáš Doktor

author

2009-07-09 09:24 UTC #0 lore raw

This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.

There is also added autotest.libhugetlbfs test.

I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)

Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

client/tests/kvm/autotest_control/libhugetlbfs.control +13 -0

diff -Narup orig/client/tests/kvm/autotest_control/libhugetlbfs.control new/client/tests/kvm/autotest_control/libhugetlbfs.control
@@ -0,0 +1,13 @@
+AUTHOR = '[email protected] (Ashwin Ganti)'
+TIME = 'MEDIUM'
+NAME = 'libhugetlbfs test'
+TEST_TYPE = 'client'
+TEST_CLASS = 'Kernel'
+TEST_CATEGORY = 'Functional'
+
+DOC = '''
+Tests basic huge pages functionality when using libhugetlbfs. For more info
+about libhugetlbfs see http://libhugetlbfs.ozlabs.org/
+'''
+
+job.run_test('libhugetlbfs', dir='/mnt')

client/tests/kvm/kvm_tests.cfg.sample +10 -0

diff -Narup orig/client/tests/kvm/kvm_tests.cfg.sample new/client/tests/kvm/kvm_tests.cfg.sample
@@ -79,6 +79,9 @@ variants:
             - bonnie:
                 test_name = bonnie
                 test_control_file = bonnie.control
+            - libhugetlbfs:
+                test_name = libhugetlbfs
+                test_control_file = libhugetlbfs.control
 
     - linux_s3:      install setup
         type = linux_s3

@@ -546,6 +549,12 @@ variants:
         only default
         image_format = raw
 
+variants:
+    - @kvm_smallpages:
+    - kvm_hugepages:
+        pre_command = "/bin/bash scripts/hugepage.sh /mnt/hugepage"
+        extra_params += " -mem-path /mnt/hugepage"
+
 
 variants:
     - @basic:

@@ -559,6 +568,7 @@ variants:
         only Fedora.8.32
         only install setup boot shutdown
         only rtl8139
+        only kvm_smallpages
     - @sample1:
         only qcow2
         only ide

client/tests/kvm/kvm_vm.py +7 -0

diff -Narup orig/client/tests/kvm/kvm_vm.py new/client/tests/kvm/kvm_vm.py
@@ -400,6 +400,13 @@ class VM:
                 self.destroy()
                 return False
 
+            if output:
+                logging.debug("qemu produced some output:\n%s", output)
+                if "alloc_mem_area" in output:
+                    logging.error("Could not allocate hugepage memory"
+                                 " -- qemu command:\n%s", qemu_command)
+                    return False
+
             logging.debug("VM appears to be alive with PID %d", self.pid)
             return True

client/tests/kvm/scripts/hugepage.sh +31 -0

diff -Narup orig/client/tests/kvm/scripts/hugepage.sh new/client/tests/kvm/scripts/hugepage.sh
@@ -0,0 +1,38 @@
+#!/bin/bash
+# Alocates enaugh hugepages for $1 memory and mount hugetlbfs to $2.
+if [ $# -ne 1 ]; then
+	echo "USAGE: $0 mem_path"
+	exit 1
+fi
+
+Hugepagesize=$(grep Hugepagesize /proc/meminfo | cut -d':'  -f 2 | \
+		 xargs | cut -d' ' -f1)
+VMS=$(expr $(echo $KVM_TEST_vms | grep -c ' ') + 1)
+VMSM=$(expr $(expr $VMS \* $KVM_TEST_mem) + $(expr $VMS \* 64 ))
+TARGET=$(expr $VMSM \* 1024 \/ $Hugepagesize)
+
+NR=$(cat /proc/sys/vm/nr_hugepages)
+while [ "$NR" -ne "$TARGET" ]; do
+	NR_="$NR";echo $TARGET > /proc/sys/vm/nr_hugepages
+	sleep 5s
+	NR=$(cat /proc/sys/vm/nr_hugepages)
+	if [ "$NR" -eq "$NR_" ] ; then
+		echo "Can not alocate $TARGET of hugepages"
+		exit 2
+	fi
+done
+
+if [ ! "$(mount | grep /mnt/hugepage |grep hugetlbfs)" ]; then
+	mkdir -p $1
+	mount -t hugetlbfs none $1 || \
+		(echo "Can not mount hugetlbfs filesystem to $1"; exit 3)
+else
+	echo "hugetlbfs filesystem already mounted"
+fi

Michael Goldish

2009-07-09 12:30 UTC #1 lore raw

I don't think you need to explicitly check for a memory allocation failure in VM.create() ("qemu produced some output ..."). VM.create() already makes sure the VM is started successfully, and prints informative failure messages if there's any problem.

Quoted 8 lines · ----- "Lukáš Doktor

This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because
it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.

Quoted 7 lines

I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better
for future occurrence)

I'll have to think about this a little before answering.

Quoted 1 line

Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

Lukáš Doktor

author

2009-07-09 12:55 UTC #2 lore raw

Hi Michael,

actually it's necessarily. qemu-kvm only put this message into the output and continue booting the guest without hugepage support. Autotest than runs all the test. Later in the output is no mention about this. You have to predict that this happend and look at debug output of all particular tests to see if qemu didn't produced this message. Using this check if qemu-kvm can't allocate the hugepage memory it fails this test, log this information and continue with next variant.

Dne 9.7.2009 14:30, Michael Goldish napsal(a):

Quoted 30 lines

I don't think you need to explicitly check for a memory allocation failure in VM.create() ("qemu produced some output ..."). VM.create() already makes sure the VM is started successfully, and prints informative failure messages if there's any problem.
Quoted 8 lines · ----- "Lukáš Doktor
This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because
it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.
Quoted 7 lines
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better
for future occurrence)
I'll have to think about this a little before answering.
Quoted 1 line
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

sudhir kumar

2009-07-10 04:38 UTC #3 lore raw

In reply to Lukáš Doktor

Why do you want to use a control file and put the libhugetlbfs as a variant of autotest in kvm? Just keeping the kvm_hugepages variant will not serve the same purpose ? I have been using hugetlbfs variant for a long but yes without pre script(I have done that manually)? Am I missing something here?
Rest all looks fine to me except you need somewhere s/enaugh/enough

2009/7/9 Lukáš Doktor <[email protected]>:

Quoted 15 lines

This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

Signature · 1 line

Sudhir Kumar

Lukáš Doktor

author

2009-07-10 06:48 UTC #4 lore raw

- kvm_hugepages variant enables us to test if (host) kvm use of hugepages works
- libhugetlbfs test inside of guest prove, that (guest) system is able to handle hugepages (independently of whether guest uses hugepages). This function is necessarily eg. if you want to run Oracle server inside the guest.

So basically this are 2 independent things, but somehow connected. If you want I can split the patches.

Dne 10.7.2009 06:38, sudhir kumar napsal(a):

Quoted 26 lines

Why do you want to use a control file and put the libhugetlbfs as a variant of autotest in kvm? Just keeping the kvm_hugepages variant will not serve the same purpose ? I have been using hugetlbfs variant for a long but yes without pre script(I have done that manually)? Am I missing something here?
Rest all looks fine to me except you need somewhere s/enaugh/enough
2009/7/9 Lukáš Doktor<[email protected]>:
Quoted 15 lines
This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

Lukáš Doktor

author

2009-07-10 08:03 UTC #5 lore raw

In reply to Lukáš Doktor

I'm sorry this patch has a bug. hugepage variant doesn't allocate enough memory with stress_boot (stress_boot uses different method to define VMS). Attached the fixed patch.

Dne 9.7.2009 11:24, Lukáš Doktor napsal(a):

Quoted 7 lines

This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.

Quoted 8 lines

I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

client/tests/kvm/autotest_control/libhugetlbfs.control +13 -0

diff -Narup orig/client/tests/kvm/autotest_control/libhugetlbfs.control new/client/tests/kvm/autotest_control/libhugetlbfs.control
@@ -0,0 +1,13 @@
+AUTHOR = '[email protected] (Ashwin Ganti)'
+TIME = 'MEDIUM'
+NAME = 'libhugetlbfs test'
+TEST_TYPE = 'client'
+TEST_CLASS = 'Kernel'
+TEST_CATEGORY = 'Functional'
+
+DOC = '''
+Tests basic huge pages functionality when using libhugetlbfs. For more info
+about libhugetlbfs see http://libhugetlbfs.ozlabs.org/
+'''
+
+job.run_test('libhugetlbfs', dir='/mnt')

client/tests/kvm/kvm_tests.cfg.sample +10 -0

diff -Narup orig/client/tests/kvm/kvm_tests.cfg.sample new/client/tests/kvm/kvm_tests.cfg.sample
@@ -79,6 +79,9 @@ variants:
             - bonnie:
                 test_name = bonnie
                 test_control_file = bonnie.control
+            - libhugetlbfs:
+                test_name = libhugetlbfs
+                test_control_file = libhugetlbfs.control
 
     - linux_s3:      install setup
         type = linux_s3

@@ -546,6 +549,12 @@ variants:
         only default
         image_format = raw
 
+variants:
+    - @kvm_smallpages:
+    - kvm_hugepages:
+        pre_command = "/bin/bash scripts/hugepage.sh /mnt/hugepage"
+        extra_params += " -mem-path /mnt/hugepage"
+
 
 variants:
     - @basic:

@@ -559,6 +568,7 @@ variants:
         only Fedora.8.32
         only install setup boot shutdown
         only rtl8139
+        only kvm_smallpages
     - @sample1:
         only qcow2
         only ide

client/tests/kvm/kvm_vm.py +7 -0

diff -Narup orig/client/tests/kvm/kvm_vm.py new/client/tests/kvm/kvm_vm.py
@@ -400,6 +400,13 @@ class VM:
                 self.destroy()
                 return False
 
+            if output:
+                logging.debug("qemu produced some output:\n%s", output)
+                if "alloc_mem_area" in output:
+                    logging.error("Could not allocate hugepage memory"
+                                 " -- qemu command:\n%s", qemu_command)
+                    return False
+
             logging.debug("VM appears to be alive with PID %d", self.pid)
             return True

client/tests/kvm/scripts/hugepage.sh +34 -0

diff -Narup orig/client/tests/kvm/scripts/hugepage.sh new/client/tests/kvm/scripts/hugepage.sh
@@ -0,0 +1,38 @@
+#!/bin/bash
+# Alocates enaugh hugepages for $1 memory and mount hugetlbfs to $2.
+if [ $# -ne 1 ]; then
+	echo "USAGE: $0 mem_path"
+	exit 1
+fi
+
+Hugepagesize=$(grep Hugepagesize /proc/meminfo | cut -d':'  -f 2 | \
+		 xargs | cut -d' ' -f1)
+VMS=$(expr $(echo $KVM_TEST_vms | grep -c ' ') + 1)
+if [ "$KVM_TEST_max_vms" ] && [ "$VMS" -lt "$KVM_TEST_max_vms" ]; then
+        VMS="$KVM_TEST_max_vms"
+fi
+VMSM=$(expr $(expr $VMS \* $KVM_TEST_mem) + $(expr $VMS \* 64 ))
+TARGET=$(expr $VMSM \* 1024 \/ $Hugepagesize)
+
+NR=$(cat /proc/sys/vm/nr_hugepages)
+while [ "$NR" -ne "$TARGET" ]; do
+	NR_="$NR";echo $TARGET > /proc/sys/vm/nr_hugepages
+	sleep 5s
+	NR=$(cat /proc/sys/vm/nr_hugepages)
+	if [ "$NR" -eq "$NR_" ] ; then
+		echo "Can not alocate $TARGET of hugepages"
+		exit 2
+	fi
+done
+
+if [ ! "$(mount | grep /mnt/hugepage |grep hugetlbfs)" ]; then
+	mkdir -p $1
+	mount -t hugetlbfs none $1 || \
+		(echo "Can not mount hugetlbfs filesystem to $1"; exit 3)
+else
+	echo "hugetlbfs filesystem already mounted"
+fi

Lukáš Doktor

author

2009-07-10 10:01 UTC #6 lore raw

[KVM_AUTOTEST] add kvm hugepage variant

In reply to Lukáš Doktor

After discussion I split the patches.

This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because
it's impossible to unmount and free hugepages before all guests are
destroyed.

Dne 9.7.2009 11:24, Lukáš Doktor napsal(a):

Quoted 7 lines

This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.

Quoted 8 lines

I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

client/tests/kvm/kvm_tests.cfg.sample +7 -0

diff -Narup orig/client/tests/kvm/kvm_tests.cfg.sample new/client/tests/kvm/kvm_tests.cfg.sample
@@ -546,6 +549,12 @@ variants:
         only default
         image_format = raw
 
+variants:
+    - @kvm_smallpages:
+    - kvm_hugepages:
+        pre_command = "/bin/bash scripts/hugepage.sh /mnt/hugepage"
+        extra_params += " -mem-path /mnt/hugepage"
+
 
 variants:
     - @basic:

@@ -559,6 +568,7 @@ variants:
         only Fedora.8.32
         only install setup boot shutdown
         only rtl8139
+        only kvm_smallpages
     - @sample1:
         only qcow2
         only ide

client/tests/kvm/kvm_vm.py +7 -0

diff -Narup orig/client/tests/kvm/kvm_vm.py new/client/tests/kvm/kvm_vm.py
@@ -400,6 +400,13 @@ class VM:
                 self.destroy()
                 return False
 
+            if output:
+                logging.debug("qemu produced some output:\n%s", output)
+                if "alloc_mem_area" in output:
+                    logging.error("Could not allocate hugepage memory"
+                                 " -- qemu command:\n%s", qemu_command)
+                    return False
+
             logging.debug("VM appears to be alive with PID %d", self.pid)
             return True

client/tests/kvm/scripts/hugepage.sh +34 -0

diff -Narup orig/client/tests/kvm/scripts/hugepage.sh new/client/tests/kvm/scripts/hugepage.sh
@@ -0,0 +1,34 @@
+#!/bin/bash
+# Alocates enough hugepages and mount hugetlbfs to $1.
+if [ $# -ne 1 ]; then
+	echo "USAGE: $0 mem_path"
+	exit 1
+fi
+
+Hugepagesize=$(grep Hugepagesize /proc/meminfo | cut -d':'  -f 2 | \
+		 xargs | cut -d' ' -f1)
+VMS=$(expr $(echo $KVM_TEST_vms | grep -c ' ') + 1)
+if [ "$KVM_TEST_max_vms" ] && [ "$VMS" -lt "$KVM_TEST_max_vms" ]; then
+        VMS="$KVM_TEST_max_vms"
+fi
+VMSM=$(expr $(expr $VMS \* $KVM_TEST_mem) + $(expr $VMS \* 64 ))
+TARGET=$(expr $VMSM \* 1024 \/ $Hugepagesize)
+
+NR=$(cat /proc/sys/vm/nr_hugepages)
+while [ "$NR" -ne "$TARGET" ]; do
+	NR_="$NR";echo $TARGET > /proc/sys/vm/nr_hugepages
+	sleep 5s
+	NR=$(cat /proc/sys/vm/nr_hugepages)
+	if [ "$NR" -eq "$NR_" ] ; then
+		echo "Can not alocate $TARGET of hugepages"
+		exit 2
+	fi
+done
+
+if [ ! "$(mount | grep /mnt/hugepage |grep hugetlbfs)" ]; then
+	mkdir -p $1
+	mount -t hugetlbfs none $1 || \
+		(echo "Can not mount hugetlbfs filesystem to $1"; exit 3)
+else
+	echo "hugetlbfs filesystem already mounted"
+fi

Lucas Meneghel Rodrigues

2009-07-20 12:58 UTC #7 lore raw

Re: [KVM_AUTOTEST] add kvm hugepage variant

Quoted 1 line · Lukáš Doktor

After discussion I split the patches.

Hi Lukáš, sorry for the delay answering your patch. Looks good to me in general, I have some remarks to make:

1) When posting patches to the autotest kvm tests, please cross post the autotest mailing list ([email protected]) and the KVM list.

2) About scripts to prepare the environment to perform tests - we've had some discussion about including shell scripts on autotest. Bottom line, autotest has a policy of not including non python code when possible [1]. So, would you mind re-creating your hugepage setup code in python and re-sending it?

Thanks for your contribution, looking forward getting it integrated to our tests.

[1] Unless when it is not practical for testing purposes - writing tests in C is just fine, for example.

Quoted 29 lines

This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because
it's impossible to unmount and free hugepages before all guests are
destroyed.
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Dne 9.7.2009 11:24, Lukáš Doktor napsal(a):
Quoted 15 lines
This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

Lukáš Doktor

author

2009-07-21 16:04 UTC #8 lore raw

Re: [KVM_AUTOTEST] add kvm hugepage variant

Well, thank you for notifications, I'll keep them in my mind.

Also the problem with mempath vs. mem-path is solved. It was just a misspell in one version of KVM.

* fixed patch attached

Dne 20.7.2009 14:58, Lucas Meneghel Rodrigues napsal(a):

Quoted 15 lines · Lukáš Doktor

Quoted 1 line
After discussion I split the patches.
Hi Lukáš, sorry for the delay answering your patch. Looks good to me in general, I have some remarks to make:
1) When posting patches to the autotest kvm tests, please cross post the autotest mailing list ([email protected]) and the KVM list.
2) About scripts to prepare the environment to perform tests - we've had some discussion about including shell scripts on autotest. Bottom line, autotest has a policy of not including non python code when possible [1]. So, would you mind re-creating your hugepage setup code in python and re-sending it?

Quoted 35 lines

Thanks for your contribution, looking forward getting it integrated to our tests.
[1] Unless when it is not practical for testing purposes - writing tests in C is just fine, for example.
Quoted 28 lines
This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because
it's impossible to unmount and free hugepages before all guests are
destroyed.
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Dne 9.7.2009 11:24, Lukáš Doktor napsal(a):
Quoted 15 lines
This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

client/tests/kvm/kvm_tests.cfg.sample +8 -0

index 5bd6eb8..70e290d 100644
@@ -555,6 +555,13 @@ variants:
         only default
         image_format = raw
 
+variants:
+    - @kvm_smallpages:
+    - kvm_hugepages:
+        hugepage_path = /mnt/hugepage
+        pre_command = "/usr/bin/python scripts/hugepage.py"
+        extra_params += " -mem-path /mnt/hugepage"
+
 
 variants:
     - @basic:

@@ -568,6 +575,7 @@ variants:
         only Fedora.8.32
         only install setup boot shutdown
         only rtl8139
+        only kvm_smallpages
     - @sample1:
         only qcow2
         only ide

client/tests/kvm/kvm_vm.py +7 -0

index 48f2916..2b97ccc 100644
@@ -412,6 +412,13 @@ class VM:
                 self.destroy()
                 return False
 
+            if output:
+                logging.debug("qemu produced some output:\n%s", output)
+                if "alloc_mem_area" in output:
+                    logging.error("Could not allocate hugepage memory"
+                                 " -- qemu command:\n%s", qemu_command)
+                    return False
+
             logging.debug("VM appears to be alive with PID %d", self.pid)
             return True

diff -Narup a/client/tests/kvm/scripts/hugepage.py b/client/tests/kvm/scripts/ hugepage.py

client/tests/kvm/scripts/hugepage.py 2009-07-21 16:47:00.000000000 +0200 renamed from client/tests/kvm/scripts/hugepage.py 1970-01-01 01:00:00.000000000 +0100 +63 -0

63 lines not on this page · raw message

sudhir kumar

2009-07-22 05:57 UTC #9 lore raw

Re: [Autotest] [KVM_AUTOTEST] add kvm hugepage variant

The patch looks to be pretty clean to me. I was running a small hugetlbfs script doing the same, but its good now as the script is being incorporated in the test.

Quoted 69 lines · Lukáš Doktor

Well, thank you for notifications, I'll keep them in my mind.
Also the problem with mempath vs. mem-path is solved. It was just a misspell in one version of KVM.
* fixed patch attached
Dne 20.7.2009 14:58, Lucas Meneghel Rodrigues napsal(a):
Quoted 17 lines · Lukáš Doktor
Quoted 2 lines
After discussion I split the patches.
Hi Lukáš, sorry for the delay answering your patch. Looks good to me in general, I have some remarks to make:
1) When posting patches to the autotest kvm tests, please cross post the autotest mailing list ([email protected]) and the KVM list.
2) About scripts to prepare the environment to perform tests - we've had some discussion about including shell scripts on autotest. Bottom line, autotest has a policy of not including non python code when possible [1]. So, would you mind re-creating your hugepage setup code in python and re-sending it?
Quoted 36 lines
Thanks for your contribution, looking forward getting it integrated to our tests.
[1] Unless when it is not practical for testing purposes - writing tests in C is just fine, for example.
Quoted 29 lines
This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Dne 9.7.2009 11:24, Lukáš Doktor napsal(a):
Quoted 16 lines
This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5
_______________________________________________
Autotest mailing list
[email protected]
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest

Signature · 1 line

Sudhir Kumar

Lucas Meneghel Rodrigues

2009-07-27 21:05 UTC #10 lore raw

Re: [Autotest] [KVM_AUTOTEST] add kvm hugepage variant

In reply to Lukáš Doktor

Quoted 1 line · Lukáš Doktor

Well, thank you for notifications, I'll keep them in my mind.

Ok Lukáš, I have reviewed your patch and have some comments to make:

(quoted diff) +0 -0

b/client/tests/kvm/kvm_tests.cfg.sample
index 5bd6eb8..70e290d 100644

client/tests/kvm/kvm_tests.cfg.sample +6 -0

@@ -555,6 +555,13 @@ variants:
         only default
         image_format = raw
 
+variants:
+    - @kvm_smallpages:
+    - kvm_hugepages:
+        hugepage_path = /mnt/hugepage
+        pre_command = "/usr/bin/python scripts/hugepage.py"
+        extra_params += " -mem-path /mnt/hugepage"

Here, I don't think it's necessary to pass /mnt/hugepage as a parameter to the script. We can rather choose a default sensible value and built into the script.

variants:
- @basic:
@@ -568,6 +575,7 @@ variants:

         only Fedora.8.32
         only install setup boot shutdown
         only rtl8139

+ only kvm_smallpages

- @sample1:
only qcow2
only ide

client/tests/kvm/kvm_vm.py +6 -0

index 48f2916..2b97ccc 100644
@@ -412,6 +412,13 @@ class VM:
                 self.destroy()
                 return False
 
+            if output:
+                logging.debug("qemu produced some output:\n%s", output)
+                if "alloc_mem_area" in output:
+                    logging.error("Could not allocate hugepage memory"
+                                 " -- qemu command:\n%s", qemu_command)
+                    return False

Here seems unnecessary to log every occasion qemu produces output, we should log it only if it contains the pattern we're looking for. Also, with kvm_subprocess recent commits, there's no more output defined. I had to change that.

logging.debug("VM appears to be alive with PID %d", self.pid) return True

diff -Narup a/client/tests/kvm/scripts/hugepage.py b/client/tests/kvm/scripts/ hugepage.py
--- a/client/tests/kvm/scripts/hugepage.py 1970-01-01 01:00:00.000000000 +0100
+++ a/client/tests/kvm/scripts/hugepage.py 2009-07-21
16:47:00.000000000 +0200
@@ -0,0 +1,63 @@
+#!/usr/bin/python
+# -*- coding: utf-8 -*-
+# Alocates enough hugepages and mount hugetlbfs
+import os, sys, time
+
+# Variables check & set
+vms = os.environ['KVM_TEST_vms'].split().__len__()
+try:
+ max_vms = int(os.environ['KVM_TEST_max_vms'])
+except KeyError:
+ max_vms = 0
+mem = int(os.environ['KVM_TEST_mem'])
+hugepage_path = os.environ['KVM_TEST_hugepage_path']
+
+fmeminfo = open("/proc/meminfo", "r")
+while fmeminfo:
+ line = fmeminfo.readline()
+ if line.startswith("Hugepagesize"):
+ dumm, hp_size, dumm = line.split()
+ break
+fmeminfo.close()
+
+if not hp_size:
+ print "Could not get Hugepagesize from /proc/meminfo file"
+ raise ValueError

Here, is allways good to put the failure reason as one of the parameters to be passed to the exception class constructor, something like:

raise ValueError("Could not get Hugepagesize from /proc/meminfo file")

+
+if vms < max_vms:
+ vms = max_vms
+
+vmsm = ((vms * mem) + (vms * 64))
+target = (vmsm * 1024 / int(hp_size))
+
+# Iteratively set # of hugepages
+fhp = open("/proc/sys/vm/nr_hugepages", "r+")
+hp = fhp.readline()
+while int(hp) < target:

+    hp_ = hp
+    fhp.write(target.__str__())
+    fhp.flush()
+    time.sleep(5)
+    fhp.seek(0)
+    hp = int(fhp.readline())
+    if hp_ == hp:

+ raise MemoryError
+fhp.close()

I liked the above approach to set the hugepage number.

+# Mount hugepage filesystem, if necessarily
+fmount = open("/proc/mounts", "r")
+mount = 1
+line = fmount.readline()
+while line:
+ if line.split()[1] == os.environ['KVM_TEST_hugepage_path']:
+ mount = 0
+ break
+ line = fmount.readline()
+fmount.close()

In the above block, it looks to me that we are more interested if we do have a hugetlbfs mount rather than checking if our defined mountpoint is mounted. We need to check in /proc/mounts whether we have a hugetlbfs mount or not instead.

+if mount:
+ if not os.path.exists(hugepage_path):
+ os.makedirs(hugepage_path)
+ cmd = "mount -t hugetlbfs none %s" % (hugepage_path)
+ if os.system(cmd):
+ raise OSError

Same as the above comment when raising exceptions. I think it's better to have our own Error class defined for the script.

Since I started fixing the original patch to fit the recent kvm_subprocess commits, I ended up re-creating the patch. I will send it to the mailing list, you tell me what you think.

Thanks!

Lucas

Lukáš Doktor

author

2009-07-10 10:04 UTC #11 lore raw

[KVM_AUTOTEST] add autotest.libhugetlbfs test

In reply to Lukáš Doktor

After discussion I split the patches.

this patch adds autotest.libhugetlbfs test which tests hugepage support inside of kvm guest.

Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

Dne 9.7.2009 11:24, Lukáš Doktor napsal(a):

Quoted 7 lines

This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.

Quoted 8 lines

I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

client/tests/kvm/autotest_control/libhugetlbfs.control +13 -0

diff -Narup orig/client/tests/kvm/autotest_control/libhugetlbfs.control new/client/tests/kvm/autotest_control/libhugetlbfs.control
@@ -0,0 +1,13 @@
+AUTHOR = '[email protected] (Ashwin Ganti)'
+TIME = 'MEDIUM'
+NAME = 'libhugetlbfs test'
+TEST_TYPE = 'client'
+TEST_CLASS = 'Kernel'
+TEST_CATEGORY = 'Functional'
+
+DOC = '''
+Tests basic huge pages functionality when using libhugetlbfs. For more info
+about libhugetlbfs see http://libhugetlbfs.ozlabs.org/
+'''
+
+job.run_test('libhugetlbfs', dir='/mnt')

client/tests/kvm/kvm_tests.cfg.sample +3 -0

diff -Narup orig/client/tests/kvm/kvm_tests.cfg.sample new/client/tests/kvm/kvm_tests.cfg.sample
@@ -79,6 +79,9 @@ variants:
             - bonnie:
                 test_name = bonnie
                 test_control_file = bonnie.control
+            - libhugetlbfs:
+                test_name = libhugetlbfs
+                test_control_file = libhugetlbfs.control
 
     - linux_s3:      install setup
         type = linux_s3

sudhir kumar

2009-07-10 10:37 UTC #12 lore raw

Re: [KVM_AUTOTEST] add autotest.libhugetlbfs test

This looks pretty clear now as the two patches do two different things. The guest large pages support is completely independent of the host support of large pages for the guest.
patches look good to me. thanks for splitting them.

2009/7/10 Lukáš Doktor <[email protected]>:

Quoted 27 lines

After discussion I split the patches.
this patch adds autotest.libhugetlbfs test which tests hugepage support inside of kvm guest.
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5
Dne 9.7.2009 11:24, Lukáš Doktor napsal(a):
Quoted 16 lines
This patch adds kvm_hugepage variant. It prepares the host system and start vm with -mem-path option. It does not clean after itself, because it's impossible to unmount and free hugepages before all guests are destroyed.
There is also added autotest.libhugetlbfs test.
I need to ask you what to do with change of qemu parameter. Newest versions are using -mempath insted of -mem-path. This is impossible to fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer (better for future occurrence)
Tested by:[email protected] on RHEL5.4 with kvm-83-72.el5

Signature · 1 line

Sudhir Kumar