linux-kernel - Re: [RESEND PATCH 0/3] mm: Add cache coloring mechanism

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:   Fri, 25 Aug 2017 11:04:23 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Dave Hansen <dave.hansen@...el.com>,
        Łukasz Daniluk <lukasz.daniluk@...el.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Cc:     lukasz.anaczkowski@...el.com
Subject: Re: [RESEND PATCH 0/3] mm: Add cache coloring mechanism

On 08/24/2017 06:08 PM, Dave Hansen wrote:
> On 08/24/2017 05:47 AM, Vlastimil Babka wrote:
>> So the obvious question, what about THPs? Their size should be enough to
>> contain all the colors with current caches, no? Even on KNL I didn't
>> find more than "32x 1 MB 16-way L2 caches". This is in addition to the
>> improved TLB performance, which you want to get as well for such workloads?
> 
> The cache in this case is "MCDRAM" which is 16GB in size.  It can be
> used as normal RAM or a cache.  This patch deals with when "MCDRAM" is
> in its cache mode.

Hm, 16GB direct mapped, that means 8k colors for 2MB THP's. Is that
really practical? Wouldn't such workload use 1GB hugetlbfs pages? Then
it's still 16 colors to manage, but could be done purely in userspace
since they should not move in physical memory and userspace can control
where to map each phase in the virtual layout.

> It's described in the "Memory Modes" slide here:
> 
>> http://www.nersc.gov/users/computational-systems/cori/configuration/knl-processor-modes/
>