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

[Eugene Batalov]

Hello Laurent,

I've made the fix. You can find it here
https://github.com/eabatalov/criu/commit/2d387e287dd3ab159fc37bbfcee71790d88666dc
I'll send it to CRIU ML once my another fix for maps008 is accepted. There
is no reason to send "huge PAGE_SIZE" fix now because one of my fixes will
introduce merge conflict after application on criu-dev after another one is
applied.

2016-08-25 12:27 GMT+03:00 Eugene Batalov <eabatalov89 at gmail.com>:

> Hello Laurent,
>
> I'll take a look and find a fix.
>
> 2016-08-25 11:52 GMT+03:00 Laurent Dufour <ldufour at linux.vnet.ibm.com>:
>
>> On 07/08/2016 15:11, Eugene Batalov wrote:
>> > Main test features:
>> > - Non trivial ps tree with non trivial anon shmem regions
>> >   (no such test exists now).
>> > - Each ps tree process continuously writes parts of anon shmem
>> >   vmas and validates these writes after restore
>> >   (required for dedup testing).
>> > - Checking simultaneous changing of anon shmem contents in different
>> >   processes.
>> >
>> > Signed-off-by: Eugene Batalov <eabatalov89 at gmail.com>
>>
>>
>> This test is not working at all on PowerPC, because the PAGE_SIZE is 64k
>> by default, and the test is not using the same magnitude when dealing
>> with the memory area's size and when dealing with this size.
>>
>> In the test, MEM_PERIOD is defined based on PAGE_SIZE, while the size of
>> the memory area are define based on 1UL arbitrary shift.
>>
>> On PowerPC this leads to a core dump of the test in proc13_func()
>> because mem2_size become negative !
>>
>> I tried to fix that by applying the attached patched but the size of the
>> manage memory areas become very large on PowerPC, about 60G of memory
>> allocated for this test.
>>
>> Could you please review this test to manage the memory area size's order
>> using PAGE_SIZE ?
>>
>> Thanks,
>> Laurent.
>>
>>
>>
>
>
> --
> Best regards,
> Eugene Batalov.
>



-- 
Best regards,
Eugene Batalov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160825/59d68918/attachment.html>