linux-kernel - Re: Plumbers 2018 - Performance and Scalability Microconference

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: <839e2703-1588-0873-00a7-d04810f403cf@linux.vnet.ibm.com>
Date:   Wed, 5 Sep 2018 18:17:59 +0200
From:   Laurent Dufour <ldufour@...ux.vnet.ibm.com>
To:     Christopher Lameter <cl@...ux.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>
Cc:     linux-kernel@...r.kernel.org,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Aaron Lu <aaron.lu@...el.com>, alex.kogan@...cle.com,
        akpm@...ux-foundation.org, boqun.feng@...il.com, brouer@...hat.com,
        dave@...olabs.net, dave.dice@...cle.com,
        Dhaval Giani <dhaval.giani@...cle.com>, ktkhai@...tuozzo.com,
        Pavel.Tatashin@...rosoft.com, paulmck@...ux.vnet.ibm.com,
        shady.issa@...cle.com, tariqt@...lanox.com, tglx@...utronix.de,
        tim.c.chen@...el.com, vbabka@...e.cz, longman@...hat.com,
        yang.shi@...ux.alibaba.com, shy828301@...il.com,
        Huang Ying <ying.huang@...el.com>, subhra.mazumdar@...cle.com,
        Steven Sistare <steven.sistare@...cle.com>, jwadams@...gle.com,
        ashwinch@...gle.com, sqazi@...gle.com,
        Shakeel Butt <shakeelb@...gle.com>, walken@...gle.com,
        rientjes@...gle.com, junaids@...gle.com,
        Neha Agarwal <nehaagarwal@...gle.com>
Subject: Re: Plumbers 2018 - Performance and Scalability Microconference



On 05/09/2018 17:10, Christopher Lameter wrote:
> On Tue, 4 Sep 2018, Daniel Jordan wrote:
> 
>>  - Promoting huge page usage:  With memory sizes becoming ever larger, huge
>> pages are becoming more and more important to reduce TLB misses and the
>> overhead of memory management itself--that is, to make the system scalable
>> with the memory size.  But there are still some remaining gaps that prevent
>> huge pages from being deployed in some situations, such as huge page
>> allocation latency and memory fragmentation.
> 
> You forgot the major issue that huge pages in the page cache are not
> supported and thus we have performance issues with fast NVME drives that
> are now able to do 3Gbytes per sec that are only possible to reach with
> directio and huge pages.
> 
> IMHO the huge page issue is just the reflection of a certain hardware
> manufacturer inflicting pain for over a decade on its poor users by not
> supporting larger base page sizes than 4k. No such workarounds needed on
> platforms that support large sizes. Things just zoom along without
> contortions necessary to deal with huge pages etc.
> 
> Can we come up with a 2M base page VM or something? We have possible
> memory sizes of a couple TB now. That should give us a million or so 2M
> pages to work with.
> 
>>  - Reducing the number of users of mmap_sem:  This semaphore is frequently
>> used throughout the kernel.  In order to facilitate scaling this longstanding
>> bottleneck, these uses should be documented and unnecessary users should be
>> fixed.
> 
> 
> Large page sizes also reduce contention there.

That's true for the page fault path, but for process's actions manipulating the
memory process's layout (mmap,munmap,madvise,mprotect) the impact is minimal
unless the code has to manipulate the page tables.

>> If you haven't already done so, please let us know if you are interested in
>> attending, or have suggestions for other attendees.
> 
> Certainly interested in attending but this overlaps supercomputing 2018 in
> Dallas Texas...
>