lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 13 Mar 2018 12:17:22 +0100
From:   Zdenek Kabelac <zkabelac@...hat.com>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Mike Snitzer <snitzer@...hat.com>,
        Mikulas Patocka <mpatocka@...hat.com>,
        Alasdair G Kergon <agk@...hat.com>
Subject: Re: Timing performance regression 4.15 to 4.16-rc1

Dne 13.3.2018 v 05:03 Al Viro napsal(a):
> On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote:
>> Hi
>>
>> I've noticed quite some drop of performance (around 15% in some cases) where
>> execution of lvm2 tests took longer time - and while tests itself should not
>> really load CPU system  - the overall running time just got bigger.
>>
>> Running bisect game pointed clearly to this commit:
>>
>> ---
>>
>> commit 44c02a2c3dc55835e9f0d8ef73966406cd805001
>> Author: Al Viro <viro@...iv.linux.org.uk>
>> Date:   Thu Oct 5 12:59:44 2017 -0400
>>
>>      dev_ioctl(): move copyin/copyout to callers
>>
>>
>> ---
>>
>> clear revert of this commit on top of 3266b5bd97eaa72793df0b6e5a106c69ccc166c4
>> (recent  ~4.16-rc4)  restored timing of tests back.
>>
>>
>> I'm not sure why - so at this moment this is just a patch causing 15% longer
>> running times on lvm2 test suite.
> 
> I find it very hard to believe, TBH.  It doesn't go anywhere near drivers/md;
> could you profile the damn thing and see where does it spend that extra time?
> 
> It really doesn't touch anything on non-sockets...


Hi

Well I'm 100% sure it's this patch causing slowdown of the test runtime
(just reverting this case makes it faster).

But even though I've already tried to create some much more simplified 
reproducer I'm still unclear what's behind it.

lvm2 alone is using sockets via i.e. udev communication - so the possible 
reason could be that used slows down  'new node' events processing in some way.

So for now the most visible reproducer is to run test in lvm2 build tree
in directory tests/:   'make check_local T=lvconvert-mirror-basic-0.sh'

I do have 'perf record' grabs if the would help anything - but looking at them 
myself there are not some directly visible things.

As said -  User+Sys timing of the running test reported by 'time' command 
remains the same - just 'real' time gets longer - which means it's waiting for 
something much longer then before  - lvm2 typically waits till udev finishes 
it's scanning.

Regards


Zdenek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ