From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id 419E78E0025 for ; Fri, 21 Sep 2018 20:06:37 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id 13-v6so13727859oiq.1 for ; Fri, 21 Sep 2018 17:06:37 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id z9-v6sor19326794ota.203.2018.09.21.17.06.36 for (Google Transport Security); Fri, 21 Sep 2018 17:06:36 -0700 (PDT) MIME-Version: 1.0 References: <153702858249.1603922.12913911825267831671.stgit@dwillia2-desk3.amr.corp.intel.com> <20180917161245.c4bb8546d2c6069b0506c5dd@linux-foundation.org> In-Reply-To: From: Dan Williams Date: Fri, 21 Sep 2018 17:06:24 -0700 Message-ID: Subject: Re: [PATCH 0/3] mm: Randomize free memory Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: "Elliott, Robert (Persistent Memory)" Cc: Kees Cook , Andrew Morton , Michal Hocko , Dave Hansen , Linux MM , Linux Kernel Mailing List , Toshi Kani On Fri, Sep 21, 2018 at 4:51 PM Elliott, Robert (Persistent Memory) wrote: > > > > -----Original Message----- > > From: linux-kernel-owner@vger.kernel.org > owner@vger.kernel.org> On Behalf Of Kees Cook > > Sent: Friday, September 21, 2018 2:13 PM > > Subject: Re: [PATCH 0/3] mm: Randomize free memory > ... > > I'd be curious to hear more about the mentioned cache performance > > improvements. I love it when a security feature actually _improves_ > > performance. :) > > It's been a problem in the HPC space: > http://www.nersc.gov/research-and-development/knl-cache-mode-performance-coe/ > > A kernel module called zonesort is available to try to help: > https://software.intel.com/en-us/articles/xeon-phi-software > > and this abandoned patch series proposed that for the kernel: > https://lkml.org/lkml/2017/8/23/195 > > Dan's patch series doesn't attempt to ensure buffers won't conflict, but > also reduces the chance that the buffers will. This will make performance > more consistent, albeit slower than "optimal" (which is near impossible > to attain in a general-purpose kernel). That's better than forcing > users to deploy remedies like: > "To eliminate this gradual degradation, we have added a Stream > measurement to the Node Health Check that follows each job; > nodes are rebooted whenever their measured memory bandwidth > falls below 300 GB/s." Robert, thanks for that! Yes, instead of run-to-run variations alternating between almost-never-conflict and nearly-always-conflict, we'll get a random / average distribution of cache conflicts.