linux-kernel - Re: weird allocation pattern in alloc_ila

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:   Mon, 9 Jan 2017 15:41:59 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Tom Herbert <tom@...bertland.com>, linux-mm@...ck.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: weird allocation pattern in alloc_ila_locks

On Mon 09-01-17 06:31:50, Eric Dumazet wrote:
> On Mon, Jan 9, 2017 at 1:58 AM, Michal Hocko <mhocko@...nel.org> wrote:
> 
> >
> > Also this seems to be an init code so I assume a modprobe would have to
> > set a non-default policy to make use of it. Does anybody do that out
> > there?
> 
> This is not init code. Whole point of rhashtable is that the resizes
> can happen anytime.
> At boot time, most rhashtable would be tiny.
> Then, when load permits, hashtables grow in size.

OK, we are mixing two things here. I was talking about alloc_ila_locks
which is an init code AFAIU.

If you are talking about alloc_bucket_locks then I would argue that the
current code doesn't work as expected as the rehash happens from a
kernel worker context and so the numa policy is out of control.

I will reply to this email with the patches I have pending here and plan
to post just to make sure we are at the same page.

-- 
Michal Hocko
SUSE Labs