linux-kernel - Re: [PATCH RFC 0/8] dcache: increase poison resistance

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>] [day] [month] [year] [list]

Message-ID: <d116ead4-f603-7e0c-e6ab-e721332c9832@oracle.com>
Date:   Sun, 13 Dec 2020 10:49:45 -0800
From:   Junxiao Bi <junxiao.bi@...cle.com>
To:     Konstantin Khlebnikov <koct9i@...il.com>
Cc:     Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-mm@...ck.org, Alexander Viro <viro@...iv.linux.org.uk>,
        Waiman Long <longman@...hat.com>,
        Gautham Ananthakrishna <gautham.ananthakrishna@...cle.com>,
        matthew.wilcox@...cle.com
Subject: Re: [PATCH RFC 0/8] dcache: increase poison resistance

On 12/11/20 11:32 PM, Konstantin Khlebnikov wrote:

> On Thu, Dec 10, 2020 at 2:01 AM Junxiao Bi <junxiao.bi@...cle.com 
> <mailto:junxiao.bi@...cle.com>> wrote:
>
>     Hi Konstantin,
>
>     We tested this patch set recently and found it limiting negative
>     dentry
>     to a small part of total memory. And also we don't see any
>     performance
>     regression on it. Do you have any plan to integrate it into
>     mainline? It
>     will help a lot on memory fragmentation issue causing by dentry slab,
>     there were a lot of customer cases where sys% was very high since
>     most
>     cpu were doing memory compaction, dentry slab was taking too much
>     memory
>     and nearly all dentry there were negative.
>
>
> Right now I don't have any plans for this. I suspect such problems will
> appear much more often since machines are getting bigger.
> So, somebody will take care of it.
We already had a lot of customer cases. It made no sense to leave so 
many negative dentry in the system, it caused memory fragmentation and 
not much benefit.
>
> First part which collects negative dentries at the end list of 
> siblings could be
> done in a more obvious way by splitting the list in two.
> But this touches much more code.
That would add new field to dentry?
>
> Last patch isn't very rigid but does non-trivial changes.
> Probably it's better to call some garbage collector thingy periodically.
> Lru list needs pressure to age and reorder entries properly.

Swap the negative dentry to the head of hash list when it get accessed? 
Extra ones can be easily trimmed when swapping, using GC is to reduce 
perf impact?

Thanks,

Junxioao.

>
> Gc could be off by default or thresholds set very high (50% of ram for 
> example).
> Final setup could be left up to owners of large systems, which needs 
> fine tuning.