[CRIU] [PATCH v3 12/12] test: add test for anon shmem dedup

[Eugene Batalov]

Oh. Looks like the problem with test performance is very simple if you've
applied all the patches from my branch.
My branch has one patch called "minimal reproducer for maps008 race
condition". It slows dows test execution very very much.
This is debugging patch. Could you revert it and rerun maps008 test on your
machine&

After revert of this patch and
#undef PAGE_SIZE
#define PAGE_SIZE (128 * 1024)

I've got good test speed:

./test/zdtm.py run -t zdtm/transition/maps008
=== Run 1/1 ================

======================= Run zdtm/transition/maps008 in h
=======================
cc -g -O2 -Wall -Werror -fno-strict-aliasing  -iquote
../lib/arch/x86/include -I../lib   maps008.c ../lib/libzdtmtst.a
../lib/libzdtmtst.a -o maps008
Start test
Test is SUID
./maps008 --pidfile=maps008.pid --outfile=maps008.out
Run criu dump
Run criu restore
Wait for zdtm/transition/maps008 to die for 0.100000
Wait for zdtm/transition/maps008 to die for 0.200000
Wait for zdtm/transition/maps008 to die for 0.400000
Removing dump/zdtm/transition/maps008/35
====================== Test zdtm/transition/maps008 PASS
=======================


2016-08-26 15:28 GMT+03:00 Eugene Batalov <eabatalov89 at gmail.com>:

> Looks like test just hasn't finished on your machine.
> Test working time is actually quite long and it looks like it is good idea
> to make it quicker.
> On my machine:
>
> ./test/zdtm.py run -t zdtm/transition/maps008
> === Run 1/1 ================
>
> ======================= Run zdtm/transition/maps008 in h
> =======================
> Start test
> Test is SUID
> ./maps008 --pidfile=maps008.pid --outfile=maps008.out
> Run criu dump
> Run criu restore
> Wait for zdtm/transition/maps008 to die for 0.100000
> Wait for zdtm/transition/maps008 to die for 0.200000
> Wait for zdtm/transition/maps008 to die for 0.400000
> Wait for zdtm/transition/maps008 to die for 0.800000
> Wait for zdtm/transition/maps008 to die for 1.600000
> Wait for zdtm/transition/maps008 to die for 3.200000
> Wait for zdtm/transition/maps008 to die for 6.400000
> Removing dump/zdtm/transition/maps008/26
> ====================== Test zdtm/transition/maps008 PASS
> =======================
>
> But if I do:
> #undef PAGE_SIZE
> #define PAGE_SIZE (64 * 1024)
>
> Then we have ~2x execution time:
> ./test/zdtm.py run -t zdtm/transition/maps008
> === Run 1/1 ================
>
> ======================= Run zdtm/transition/maps008 in h
> =======================
> cc -g -O2 -Wall -Werror -fno-strict-aliasing  -iquote
> ../lib/arch/x86/include -I../lib   maps008.c ../lib/libzdtmtst.a
> ../lib/libzdtmtst.a -o maps008
> Start test
> Test is SUID
> ./maps008 --pidfile=maps008.pid --outfile=maps008.out
> Run criu dump
> Run criu restore
> Wait for zdtm/transition/maps008 to die for 0.100000
> Wait for zdtm/transition/maps008 to die for 0.200000
> Wait for zdtm/transition/maps008 to die for 0.400000
> Wait for zdtm/transition/maps008 to die for 0.800000
> Wait for zdtm/transition/maps008 to die for 1.600000
> Wait for zdtm/transition/maps008 to die for 3.200000
> Wait for zdtm/transition/maps008 to die for 6.400000
> Wait for zdtm/transition/maps008 to die for 12.800000
> Removing dump/zdtm/transition/maps008/35
> ====================== Test zdtm/transition/maps008 PASS
> =======================
>
> So I'll find some way to speed it up.
>
>
> 2016-08-26 10:12 GMT+03:00 Laurent Dufour <ldufour at linux.vnet.ibm.com>:
>
>> On 25/08/2016 18:15, Eugene Batalov wrote:
>> > Thank you, Laurent.
>> >
>> > I've checked bugfix again and found a small bug in it. It is in place
>> > of memX_size variables assignment (I've redefined them locally o_0 and
>> > test on my machine wasn't failing).
>> > Please try updated branch
>> > https://github.com/eabatalov/criu/commit/f4d3a0f6235c47622fe
>> 3c383e201044806b8d6aa
>>
>> Hi Eugene,
>>
>> This is better but there is still something wrong happening.
>>
>> Here is the output I got when the test on my victim node:
>>
>> laurent at frags:~/work/criu/test$ sudo ./zdtm.py run -t
>> zdtm/transition/maps008
>> === Run 1/1 ================
>>
>> ======================= Run zdtm/transition/maps008 in h
>> =======================
>> Start test
>> Test is SUID
>> ./maps008 --pidfile=maps008.pid --outfile=maps008.out
>> Run criu dump
>> Run criu restore
>> Wait for zdtm/transition/maps008 to die for 0.100000
>> Wait for zdtm/transition/maps008 to die for 0.200000
>> Wait for zdtm/transition/maps008 to die for 0.400000
>> Wait for zdtm/transition/maps008 to die for 0.800000
>> Wait for zdtm/transition/maps008 to die for 1.600000
>> Wait for zdtm/transition/maps008 to die for 3.200000
>> Wait for zdtm/transition/maps008 to die for 6.400000
>> Wait for zdtm/transition/maps008 to die for 12.800000
>> Wait for zdtm/transition/maps008 to die for 25.600000
>> ####### Test zdtm/transition/maps008 FAIL at zdtm/transition/maps008 die
>> #######
>> Test output: ================================
>> 09:08:15.769:    26: PASS
>>
>>  <<< ================================
>> Traceback (most recent call last):
>>   File "zdtm.py", line 1585, in <module>
>>     do_run_test(tinfo[0], tinfo[1], tinfo[2], tinfo[3])
>>   File "zdtm.py", line 1108, in do_run_test
>>     t.kill()
>>   File "zdtm.py", line 418, in kill
>>     os.kill(int(self.__pid), sig)
>> OSError: [Errno 3] No such process
>> ##################################### FAIL
>> #####################################
>>
>>
>> So the test's output is mentioning "PASS" while zdtm.py is saying that
>> it fails.
>> I'm wondering if there are some maps008 processes still running when
>> zdtm is waiting for the test to end.
>>
>> Cheers,
>> Laurent.
>>
>>
>
>
> --
> Best regards,
> Eugene Batalov.
>



-- 
Best regards,
Eugene Batalov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160826/8e103c40/attachment-0001.html>