On Fri, 2010-07-02 at 10:37 +0800, Amos Kong wrote:
> On Thu, Jul 01, 2010 at 04:51:58PM +0300, Michael Goldish wrote:
> > On 07/01/2010 04:30 PM, Lucas Meneghel Rodrigues wrote:
> > > On Thu, 2010-07-01 at 16:08 +0300, Michael Goldish wrote:
> > >> On 07/01/2010 04:00 PM, [email protected] wrote:
> > >>> From: Amos Kong <[email protected]>
> > >>>
> > >>> After testing with hugepages, memory is not released, it will cause the
> > >>> memory
> > >>> lack in host. This will make the host running extremely slow and will
> > >>> influence
> > >>> other tests to be executed.
> > >>>
> > >>> Signed-off-by: Yiqiao Pu <[email protected]>
> > >>> Signed-off-by: Amos Kong <[email protected]>
> > >>> ---
> > >>> client/tests/kvm/tests_base.cfg.sample | 1 +
> > >>> 1 files changed, 1 insertions(+), 0 deletions(-)
> > >>>
> > >>> diff --git a/client/tests/kvm/tests_base.cfg.sample
> > >>> b/client/tests/kvm/tests_base.cfg.sample
> > >>> index 7f59bfc..1ed5237 100644
> > >>> --- a/client/tests/kvm/tests_base.cfg.sample
> > >>> +++ b/client/tests/kvm/tests_base.cfg.sample
> > >>> @@ -1452,6 +1452,7 @@ variants:
> > >>> - @smallpages:
> > >>> - hugepages:
> > >>> pre_command += " scripts/hugepage.py /mnt/kvm_hugepage;"
> > >>> + post_command += " echo 0 > /proc/sys/vm/nr_hugepages; umount
> > >>> /mnt/kvm_hugepage;"
> > >>> extra_params += " -mem-path /mnt/kvm_hugepage"
> > >>>
> > >>>
> > >>
> > >> post_command is executed after every test. This means that at the end of
> > >> the boot test for example, while the VM is still alive, the command will
> > >> be executed. Won't that bother the VM?
>
> If guest is still alive, echo will be successful, umount will fail, it won't
> effect guest. Memory will be released when guest is died.
>
> > > Oops, I guess I was too hasty again. Indeed, I think at least we'll have
> > > trouble unmounting the hugepage directory. We might think of another
> > > solution instead of this one.
>
> No need another solution.
>
> > If umount is supposed to fail that's a good thing. Can we reverse the
> > order of the commands? If we can, we can try:
> >
> > post_command += " umount /mnt/kvm_hugepage && echo 0 >
> > /proc/sys/vm/nr_hugepages;"
> >
> > so at the end of each test umount will be attempted, and only if it
> > succeeds, echo 0 ... will be executed. If there are living VMs umount
> > will fail (hopefully) and no harm will be done. Of course this
> > post_command has to be made noncritical.
>
>
> It the guest is also live at the end of the job, umount will fail, echo
> couldn't be executed, the memory will never be released.
I just discovered that this post command is giving us problems, at least
on RHEL5.X hosts. The first one or 2 tests with hugepages works OK, then
the subsequents are failing
/usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor
unix:'/tmp/monitor-humanmonitor1-20100713-021212-KjSi',server,nowait -serial
unix:'/tmp/serial-20100713-021212-KjSi',server,nowait -drive
file='/tmp/kvm_autotest_root/images/rhel5-32.qcow2',if=virtio,boot=on -net
nic,vlan=0,model=virtio,macaddr='52:54:00:12:36:80' -net
tap,vlan=0,script='/usr/local/autotest/tests/kvm/scripts/qemu-ifup',downscript='no'
-m 1024 -smp 2 -drive
file='/tmp/kvm_autotest_root/isos/linux/RHEL-5.5-i386-DVD.iso',index=2,media=cdrom
-redir tcp:5000::22 -vnc :0 -mem-path /mnt/kvm_hugepage
07/13 10:18:42 DEBUG|kvm_subpro:0699| (qemu) alloc_mem_area: can't mmap
hugetlbfs pages: Cannot allocate memory
Because the 1st command is executing successfuly, then blowing up the
subsequent tests
The correct command should be as we spoke
post_command += " umount /mnt/kvm_hugepage && echo 0 >
/proc/sys/vm/nr_hugepages;"
So I will test here and if everything goes well I will update the config file
upstream.
_______________________________________________
Autotest mailing list
[email protected]
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
