Date:   Tue, 4 Sep 2018 12:50:00 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Jacek Tomaka <Jacek.Tomaka@...zta.fm>
Cc:     kirill.shutemov@...ux.intel.com, mingo@...nel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: Hugepages mixed with stacks in process address space

(cc linux-mm).

And thanks.

On Tue, 04 Sep 2018 17:08:34 +0200 Jacek Tomaka <Jacek.Tomaka@...zta.fm> wrote:

> Hello, 
> 
> I was trying to track down the performance differences of one of my applications 
> between running it on kernel used in Centos 7.4 and the latest 4.x version. 
> On 4.x kernels its performance depended on the run and the variability 
> was more than 30%. 
> 
> Bisecting showed that my issue  was introduced by : 
> fd8526ad14c182605e42b64646344b95befd9f94 :x86/mm: Implement ASLR for 
> hugetlb mappings
> 
> But it was not the ASLR aspect of that commit that created the issue but the 
> change from bottom-up to top-down unmapped area lookup when allocating 
> huge pages. 
> 
> After that change, the huge page allocations could become intertwined with 
> stacks. Before, the stacks and huge pages were on the other side of the process 
> address space. 
> 
> The machine i am seeing it on is Knights Landing 7250, with 68 cores x 4 
> hyper-threads. 
> 
> My application spawns 272 threads and each thread allocates its memory - a 
> couple of 2MB huge pages and does some computation, dominated by memory 
> accesses. 
> 
> My theory is that because KNL has 8-way 2MB TLB,  when the huge pages are 
> exactly 8 pages apart they collide.  And this is where the variability comes from, 
> if the stacks come in between, they increase chances of them colliding. 
> 
> I do realise that the application is (I am ) doing a few things dubiously:  it
> allocates memory on each thread and each huge page separately.  But i thought
> you might want to know about this behaviour change. 
> 
> When i allocate all my memory before i start threads, the problem goes away. 
> 
> /proc/PID/maps: 
> After change: 
> 7f5e06a00000-7f5e06c00000 rw-p 00000000 00:0f 31809                      /anon_hugepage (deleted)
> 7f5e06c00000-7f5e06e00000 rw-p 00000000 00:0f 29767                      /anon_hugepage (deleted)
> 7f5e06e00000-7f5e07000000 rw-p 00000000 00:0f 30787                      /anon_hugepage (deleted)
> 7f5e07000000-7f5e07200000 rw-p 00000000 00:0f 30786                      /anon_hugepage (deleted)
> 7f5e07200000-7f5e07400000 rw-p 00000000 00:0f 28744                      /anon_hugepage (deleted)
> 7f5e075ff000-7f5e07600000 ---p 00000000 00:00 0 
> 7f5e07600000-7f5e07e00000 rw-p 00000000 00:00 0 
> 7f5e07e00000-7f5e08000000 rw-p 00000000 00:0f 30785                      /anon_hugepage (deleted)
> 7f5e08000000-7f5e08021000 rw-p 00000000 00:00 0 
> 7f5e08021000-7f5e0c000000 ---p 00000000 00:00 0 
> 7f5e0c000000-7f5e0c021000 rw-p 00000000 00:00 0 
> 7f5e0c021000-7f5e10000000 ---p 00000000 00:00 0 
> 7f5e10000000-7f5e10021000 rw-p 00000000 00:00 0 
> 7f5e10021000-7f5e14000000 ---p 00000000 00:00 0 
> 7f5e14200000-7f5e14400000 rw-p 00000000 00:0f 29765                      /anon_hugepage (deleted)
> 7f5e14400000-7f5e14600000 rw-p 00000000 00:0f 28743                      /anon_hugepage (deleted)
> 7f5e14600000-7f5e14800000 rw-p 00000000 00:0f 29764                      /anon_hugepage (deleted)
> (...)
> 
> Before change: 
> 2aaaaac00000-2aaaaae00000 rw-p 00000000 00:0f 25582                      /anon_hugepage (deleted)
> 2aaaaae00000-2aaaab000000 rw-p 00000000 00:0f 25583                      /anon_hugepage (deleted)
> 2aaaab000000-2aaaab200000 rw-p 00000000 00:0f 25584                      /anon_hugepage (deleted)
> 2aaaab200000-2aaaab400000 rw-p 00000000 00:0f 25585                      /anon_hugepage (deleted)
> 2aaaab400000-2aaaab600000 rw-p 00000000 00:0f 25601                      /anon_hugepage (deleted)
> 2aaaab600000-2aaaab800000 rw-p 00000000 00:0f 25599                      /anon_hugepage (deleted)
> 2aaaab800000-2aaaaba00000 rw-p 00000000 00:0f 25602                      /anon_hugepage (deleted)
> 2aaaaba00000-2aaaabc00000 rw-p 00000000 00:0f 26652                      /anon_hugepage (deleted)
> (...)
> 7fc4f0021000-7fc4f4000000 ---p 00000000 00:00 0 
> 7fc4f4000000-7fc4f4021000 rw-p 00000000 00:00 0 
> 7fc4f4021000-7fc4f8000000 ---p 00000000 00:00 0 
> 7fc4f8000000-7fc4f8021000 rw-p 00000000 00:00 0 
> 7fc4f8021000-7fc4fc000000 ---p 00000000 00:00 0 
> 7fc4fc000000-7fc4fc021000 rw-p 00000000 00:00 0 
> 7fc4fc021000-7fc500000000 ---p 00000000 00:00 0 
> 7fc500000000-7fc500021000 rw-p 00000000 00:00 0 
> 7fc500021000-7fc504000000 ---p 00000000 00:00 0 
> 7fc504000000-7fc504021000 rw-p 00000000 00:00 0 
> 7fc504021000-7fc508000000 ---p 00000000 00:00 0 
> 7fc508000000-7fc508021000 rw-p 00000000 00:00 0 
> 7fc508021000-7fc50c000000 ---p 00000000 00:00 0 
> (...)
> 
> I was wondering if this intertwined stacks and hugepages is an expected 
> feature of ASLR? If not, maybe mmap's MAP_STACK flag could finally start 
> to be used by the kernel to keep all the stacks together in process address 
> space?
> 
> Or should users just not allocate huge pages on separate threads?
> 
> MAP_STACK could also be used to mark a VMA as a mapping for stack, 
> (if there are flags left) to re-implement: 
> 65376df582174ffcec9e6471bf5b0dd79ba05e4a proc: revert /proc/<pid>/maps [stack:TID] annotation
> correctly, as having these pieces of information in place would greatly 
> simplify my investigation. 
> 
> Regards.
> Jacek Tomaka

Powered by blists - more mailing lists