From: "Huang\, Ying" <ying.huang@intel.com> To: Christopher Lameter <cl@linux.com> Cc: Daniel Jordan <daniel.m.jordan@oracle.com>, <linux-kernel@vger.kernel.org>, "linux-mm\@kvack.org" <linux-mm@kvack.org>, Aaron Lu <aaron.lu@intel.com>, <alex.kogan@oracle.com>, <akpm@linux-foundation.org>, <boqun.feng@gmail.com>, <brouer@redhat.com>, <dave@stgolabs.net>, <dave.dice@oracle.com>, Dhaval Giani <dhaval.giani@oracle.com>, <ktkhai@virtuozzo.com>, <ldufour@linux.vnet.ibm.com>, <Pavel.Tatashin@microsoft.com>, <paulmck@linux.vnet.ibm.com>, <shady.issa@oracle.com>, <tariqt@mellanox.com>, <tglx@linutronix.de>, <tim.c.chen@intel.com>, <vbabka@suse.cz>, <longman@redhat.com>, <yang.shi@linux.alibaba.com>, <shy828301@gmail.com>, <subhra.mazumdar@oracle.com>, Steven Sistare <steven.sistare@oracle.com>, <jwadams@google.com>, <ashwinch@google.com>, <sqazi@google.com>, Shakeel Butt <shakeelb@google.com>, <walken@google.com>, <rientjes@google.com>, <junaids@google.com>, Neha Agarwal <nehaagarwal@google.com> Subject: Re: Plumbers 2018 - Performance and Scalability Microconference Date: Thu, 06 Sep 2018 09:58:17 +0800 [thread overview] Message-ID: <877ejzqtdy.fsf@yhuang-dev.intel.com> (raw) In-Reply-To: <01000165aa490dc9-64abf872-afd1-4a81-a46d-a50d0131de93-000000@email.amazonses.com> (Christopher Lameter's message of "Wed, 5 Sep 2018 15:10:39 +0000") Hi, Christopher, Christopher Lameter <cl@linux.com> writes: > 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. Yes. That is an important gap for huge page. Although we have huge page cache support for tmpfs, we lacks that for normal file systems. > 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. That sounds a good idea. Don't know whether someone has tried this. >> - 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. Yes. >> 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... Sorry to know this. It appears that there are too many conferences in November... Best Regards, Huang, Ying
WARNING: multiple messages have this Message-ID (diff)
From: "Huang\, Ying" <ying.huang@intel.com> To: Christopher Lameter <cl@linux.com> Cc: Daniel Jordan <daniel.m.jordan@oracle.com>, linux-kernel@vger.kernel.org, "linux-mm@kvack.org" <linux-mm@kvack.org>, Aaron Lu <aaron.lu@intel.com>, alex.kogan@oracle.com, akpm@linux-foundation.org, boqun.feng@gmail.com, brouer@redhat.com, dave@stgolabs.net, dave.dice@oracle.com, Dhaval Giani <dhaval.giani@oracle.com>, ktkhai@virtuozzo.com, ldufour@linux.vnet.ibm.com, Pavel.Tatashin@microsoft.com, paulmck@linux.vnet.ibm.com, shady.issa@oracle.com, tariqt@mellanox.com, tglx@linutronix.de, tim.c.chen@intel.com, vbabka@suse.cz, longman@redhat.com, yang.shi@linux.alibaba.com, shy828301@gmail.com, subhra.mazumdar@oracle.com, Steven Sistare <steven.sistare@oracle.com>, jwadams@google.com, ashwinch@google.com, sqazi@google.com, Shakeel Butt <shakeelb@google.com>, walken@google.com, rientjes@google.com, junaids@google.com, Neha Agarwal <nehaagarwal@google.com> Subject: Re: Plumbers 2018 - Performance and Scalability Microconference Date: Thu, 06 Sep 2018 09:58:17 +0800 [thread overview] Message-ID: <877ejzqtdy.fsf@yhuang-dev.intel.com> (raw) In-Reply-To: <01000165aa490dc9-64abf872-afd1-4a81-a46d-a50d0131de93-000000@email.amazonses.com> (Christopher Lameter's message of "Wed, 5 Sep 2018 15:10:39 +0000") Hi, Christopher, Christopher Lameter <cl@linux.com> writes: > 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. Yes. That is an important gap for huge page. Although we have huge page cache support for tmpfs, we lacks that for normal file systems. > 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. That sounds a good idea. Don't know whether someone has tried this. >> - 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. Yes. >> 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... Sorry to know this. It appears that there are too many conferences in November... Best Regards, Huang, Ying
next prev parent reply other threads:[~2018-09-06 1:58 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-04 21:28 Plumbers 2018 - Performance and Scalability Microconference Daniel Jordan 2018-09-04 21:28 ` Daniel Jordan 2018-09-05 6:38 ` Mike Rapoport 2018-09-05 19:51 ` Pasha Tatashin 2018-09-06 5:49 ` Mike Rapoport 2018-09-05 15:10 ` Christopher Lameter 2018-09-05 15:10 ` Christopher Lameter 2018-09-05 16:17 ` Laurent Dufour 2018-09-05 17:11 ` Christopher Lameter 2018-09-05 23:01 ` Thomas Gleixner 2018-09-06 7:45 ` Laurent Dufour 2018-09-06 1:58 ` Huang, Ying [this message] 2018-09-06 1:58 ` Huang, Ying 2018-09-06 14:41 ` Christopher Lameter 2018-09-07 2:17 ` Huang, Ying 2018-09-07 2:17 ` Huang, Ying 2018-09-06 21:36 ` Mike Kravetz 2018-09-07 0:52 ` Hugh Dickins 2018-09-08 4:13 ` John Hubbard 2018-09-08 4:13 ` John Hubbard 2018-09-10 17:09 ` Waiman Long 2018-09-10 17:20 ` Davidlohr Bueso 2018-09-10 17:34 ` John Hubbard 2018-09-10 17:34 ` John Hubbard 2018-09-11 0:29 ` Daniel Jordan 2018-09-11 0:29 ` Daniel Jordan 2018-09-11 13:52 ` Waiman Long 2018-09-11 0:38 ` Daniel Jordan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=877ejzqtdy.fsf@yhuang-dev.intel.com \ --to=ying.huang@intel.com \ --cc=Pavel.Tatashin@microsoft.com \ --cc=aaron.lu@intel.com \ --cc=akpm@linux-foundation.org \ --cc=alex.kogan@oracle.com \ --cc=ashwinch@google.com \ --cc=boqun.feng@gmail.com \ --cc=brouer@redhat.com \ --cc=cl@linux.com \ --cc=daniel.m.jordan@oracle.com \ --cc=dave.dice@oracle.com \ --cc=dave@stgolabs.net \ --cc=dhaval.giani@oracle.com \ --cc=junaids@google.com \ --cc=jwadams@google.com \ --cc=ktkhai@virtuozzo.com \ --cc=ldufour@linux.vnet.ibm.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=longman@redhat.com \ --cc=nehaagarwal@google.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=rientjes@google.com \ --cc=shady.issa@oracle.com \ --cc=shakeelb@google.com \ --cc=shy828301@gmail.com \ --cc=sqazi@google.com \ --cc=steven.sistare@oracle.com \ --cc=subhra.mazumdar@oracle.com \ --cc=tariqt@mellanox.com \ --cc=tglx@linutronix.de \ --cc=tim.c.chen@intel.com \ --cc=vbabka@suse.cz \ --cc=walken@google.com \ --cc=yang.shi@linux.alibaba.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.