linux-kernel - Re: [PATCH 2/3] sparc64: Add 16GB hugepage support

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] [day] [month] [year] [list]

Date:   Wed, 26 Jul 2017 13:10:00 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     nitin.m.gupta@...cle.com
Cc:     mike.kravetz@...cle.com, kirill.shutemov@...ux.intel.com,
        tom.hromatka@...cle.com, mhocko@...e.com, mingo@...nel.org,
        akpm@...ux-foundation.org, steve.capper@....com, hughd@...gle.com,
        punit.agrawal@....com, bob.picco@...cle.com,
        pasha.tatashin@...cle.com, steven.sistare@...cle.com,
        paul.gortmaker@...driver.com, thomas.tai@...cle.com,
        atish.patra@...cle.com, sparclinux@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] sparc64: Add 16GB hugepage support

From: Nitin Gupta <nitin.m.gupta@...cle.com>
Date: Wed, 26 Jul 2017 11:35:28 -0700

> 
> 
> On 07/20/2017 01:04 PM, David Miller wrote:
>> From: Nitin Gupta <nitin.m.gupta@...cle.com>
>> Date: Thu, 13 Jul 2017 14:53:24 -0700
>> 
>>> Testing:
>>>
>>> Tested with the stream benchmark which allocates 48G of
>>> arrays backed by 16G hugepages and does RW operation on
>>> them in parallel.
>> 
>> It would be great if we started adding tests under
>> tools/testing/selftests so that other people can recreate
>> your tests/benchmarks.
>> 
> 
> Yes, I would like to add the stream benchmark to selftests too.
> I will check if our internal version of stream can be released.

That would be great.

>> This macro is getting way out of control, every TLB/TSB miss is
>> going to invoke this sequence of code.
>> 
>> Yes, it's just a two cycle constant load, a test modifying the
>> condition codes, and an easy to predict branch.
>> 
>> But every machine will eat this overhead, even if they don't use
>> hugepages or don't set the 16GB knob.
>> 
>> I think we can do better, using code patching or similar.
>> 
>> Once the knob is set, you can know for sure that this code path
>> will never actually be taken.
> 
> The simplest way I can think of is to add CONFIG_SPARC_16GB_HUGEPAGE
> and exclude PUD check if not enabled.  Would this be okay?

I am saying above to do a run-time code patch.

Kconfig knobs are completely pointless in this kind of situation
since every distribution is going to turn the thing on so essentially
all real users eat the overhead if you do it the Kconfig way.

So do a run-time code patch instead, thank you.