[SSSD] [PATCH 1/1] tests: Don't assume absolute test dir in test_io.c

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Mon May 19 14:55:45 UTC 2014


On 05/19/2014 10:33 AM, Lukas Slebodnik wrote:
> On (17/05/14 01:14), Nikolai Kondrashov wrote:
>> On 05/16/2014 11:32 PM, Lukas Slebodnik wrote:
>>> On (16/04/14 21:30), Nikolai Kondrashov wrote:
>>>> In my case there is no beneficial performance difference when running with
>>>> valgrind. There is about 25% improvement using /dev/shm when running with
>>>> coverage enabled, but even in a VM it takes less than a minute on my machine.
>>>>
>>> I was waiting for pshing patch to the upstream.
>>> This is a reason of late reply.
>>>
>>>> I will use /dev/shm and will mess with moving test results around, when/if
>>>> I'll need to tune the performance, but for now I'd prefer to keep my CI code
>>>> simple and use relative directories.
>>>>
>>> I have totally different results. The most problematic is sysdb test,
>>> because there is a lof of IO operations.
>>
> It might look I was exaggerating in my previous mail.

No, it didn't really.

> "ramdisk" is 58x faster then HDD.
> "ramdisk" is 26x faster then HDD.

Out of curiosity: why is it so much faster? Does the code sync to disc often?

I did some light tests and while I don't see such a dramatic difference on my
setup, it is still considerable. A "make check" with Valgrind took 26 minutes
with test-dir on HDD and 16 minutes on ramdisk.

Although I tried investingating this a while ago (and will try again later),
I'm not sure why it takes such a long time on my machine. This is not very
important right now, though, as I will need to optimize for CI VMs first.

I was using this command, without setting CK_FORK:

     make -j 4 check LOG_COMPILER=libtool \
                     'LOG_FLAGS=--mode=execute \
                                 valgrind \
                                     --error-exitcode=99 \
                                     --trace-children=yes \
                                     --trace-children-skip=/* \
                                     --leak-check=full'

I'll need to improve child filtering, though.

>> I admit I didn't test this thoroughly and might have hit a corner case and
>> perhaps I was biased. I'll retry my tests properly once I get to the point of
>> optimizing performance.
> Running tests in ramdisk is necessary for developers to pass tests
> in reasonable time. It is not optimization, it is well known fact
> and I will appreciate if continous integration is aware of this fact.

Let's skip discussion on term use. The request is valid as the time difference
is not to be sneezed at. I've already implemented using /dev/shm/<subdir> as
storage location for running tests and moving it to the build directory for
archival.

Sincerely,
Nick



More information about the sssd-devel mailing list