linux-kernel - Re: [v4 1/1] mm: Adaptive hash table scaling

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]

Message-ID: <20170521163506.GA8096@two.firstfloor.org>
Date:   Sun, 21 May 2017 09:35:06 -0700
From:   Andi Kleen <andi@...stfloor.org>
To:     Pasha Tatashin <pasha.tatashin@...cle.com>
Cc:     Andi Kleen <andi@...stfloor.org>, akpm@...ux-foundation.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, mhocko@...nel.org
Subject: Re: [v4 1/1] mm: Adaptive hash table scaling

On Sun, May 21, 2017 at 08:58:25AM -0400, Pasha Tatashin wrote:
> Hi Andi,
> 
> Thank you for looking at this. I mentioned earlier, I would not want to
> impose a cap. However, if you think that for example dcache needs a cap,
> there is already a mechanism for that via high_limit argument, so the client

Lots of arguments are not the solution. Today this only affects a few
highend systems, but we'll see much more large memory systems in the
future. We don't want to have all these users either waste their memory,
or apply magic arguments.

> can be changed to provide that cap. However, this particular patch addresses
> scaling problem for everyone by making it scale with memory at a slower
> pace.

Yes your patch goes in the right direction and should be applied.

Just could be even more aggressive.

Long term probably all these hash tables need to be converted to rhash
to dynamically resize.

-Andi