[CRIU] [PATCH] zdtm/static/maps06: removed hardcoded page-size

[Dmitry Safonov]

2018-06-06 16:47 GMT+01:00 Adrian Reber <areber at redhat.com>:
> On Wed, Jun 06, 2018 at 04:12:51PM +0100, Dmitry Safonov wrote:
>> 2018-06-06 15:52 GMT+01:00 Adrian Reber <areber at redhat.com>:
>> > On Wed, Jun 06, 2018 at 03:44:32PM +0100, Dmitry Safonov wrote:
>> >> 2018-06-05 20:58 GMT+01:00 Adrian Reber <adrian at lisas.de>:
>> >> [..]
>> >> > @@ -23,21 +23,26 @@ int main(int argc, char ** argv)
>> >> >         if (fd < 0)
>> >> >                 return 1;
>> >> >
>> >> > -       ftruncate(fd, 4096);
>> >> > +       ftruncate(fd, ps);
>> >> > +
>> >> > +       if (ps == 0x1000)
>> >> > +               test_size = 10240;
>> >> > +       else
>> >> > +               test_size = 512;
>> >>
>> >> Is it worth to calculate test_size dynamically based on ps?
>> >> Like will the test work on both 16k and 64k pages?
>> >
>> > Without that the test failed as the result (ps * test_size *4) for mmap()'s
>> > length overflowed. I have not checked if it works when changing ps or
>> > test_size to a 64bit value.
>>
>> No, what I meant is that you've chosen 512 static value.
>> Will the test work both for 16k and 64k pages?
>> Or test_size will differ between 16k/64k - then probably
>> it would be worth to calculate it with a division.
>
> I first thought that was what you were asking, but then I was not so
> sure any more. Yes, for 16K pages it is not perfect. That is correct.
>
> I only tested with 64K a 4K pages.
>
> I thought about a division, but wanted to keep it simple.
>
> I can do a new version with a division.

I'm not really sure if it's worth to create a new version with a division.
If it you expect it to work with the current code on 16k, it's fine for me.
I haven't carefully looked at code to catch if it will or will not work
with 512 value.

Thanks,
             Dmitry