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  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:   Fri, 11 Sep 2020 17:37:51 -0500
From:   Michael Larabel <>
To:     Linus Torvalds <>
Cc:     Ted Ts'o <>,
        Andreas Dilger <>,
        Ext4 Developers List <>
Subject: Re: Kernel Benchmarking

On 9/11/20 5:07 PM, Linus Torvalds wrote:
> On Fri, Sep 11, 2020 at 9:19 AM Linus Torvalds
> <> wrote:
>> Ok, it's probably simply that fairness is really bad for performance
>> here in general, and that special case is just that - a special case,
>> not the main issue.
> Ahh. It turns out that I should have looked more at the fault path
> after all. It was higher up in the profile, but I ignored it because I
> found that lock-unlock-lock pattern lower down.
> The main contention point is actually filemap_fault(). Your apache
> test accesses the 'test.html' file that is mmap'ed into memory, and
> all the threads hammer on that one single file concurrently and that
> seems to be the main page lock contention.
> Which is really sad - the page lock there isn't really all that
> interesting, and the normal "read()" path doesn't even take it. But
> faulting the page in does so because the page will have a long-term
> existence in the page tables, and so there's a worry about racing with
> truncate.
> Interesting, but also very annoying.
> Anyway, I don't have a solution for it, but thought I'd let you know
> that I'm still looking at this.
>                  Linus

I've been running your EXT4 patch on more systems and with some 
additional workloads today. While not the original problem, the patch 
does seem to help a fair amount for the MariaDB database sever. This 
wasn't one of the workloads regressing on 5.9 but at least with the 
systems tried so far the patch does make a meaningful improvement to the 
performance. I haven't run into any apparent issues with that patch so 
continuing to try it out on more systems and other database/server 


Powered by blists - more mailing lists