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]

Message-ID: <CANn89iLoC6uL8rfr_GWfuPeKasgw=JiuciSDN6EQBC0yFsgbww@mail.gmail.com>
Date:   Mon, 9 Jan 2017 06:31:50 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Michal Hocko <mhocko@...nel.org>
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, 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.

Yes, some applications make some specific choices about NUMA policies.

It would be perfectly possible to amend rhashtable to make sure that
allocations can respect this strategy.
(ie the NUMA policy could be an attribute of the rhashtable, instead
of being implicitly given by current process)