Re: Plumbers 2018 - Performance and Scalability Microconference

[Davidlohr Bueso]

On Mon, 10 Sep 2018, Waiman Long wrote:

> On 09/08/2018 12:13 AM, John Hubbard wrote:
> > Hi Daniel and all,
> >
> > I'm interested in the first 3 of those 4 topics, so if it doesn't conflict with HMM topics or
> > fix-gup-with-dma topics, I'd like to attend. GPUs generally need to access large chunks of
> > memory, and that includes migrating (dma-copying) pages around.
> >
> > So for example a multi-threaded migration of huge pages between normal RAM and GPU memory is an
> > intriguing direction (and I realize that it's a well-known topic, already). Doing that properly
> > (how many threads to use?) seems like it requires scheduler interaction.
> >
> > It's also interesting that there are two main huge page systems (THP and Hugetlbfs), and I sometimes
> > wonder the obvious thing to wonder: are these sufficiently different to warrant remaining separate,
> > long-term?  Yes, I realize they're quite different in some ways, but still, one wonders. :)
>
> One major difference between hugetlbfs and THP is that the former has to
> be explicitly managed by the applications that use it whereas the latter
> is done automatically without the applications being aware that THP is
> being used at all. Performance wise, THP may or may not increase
> application performance depending on the exact memory access pattern,
> though the chance is usually higher that an application will benefit
> than suffer from it.
>
> If an application know what it is doing, using hughtblfs can boost
> performance more than it can ever achieved by THP. Many large enterprise
> applications, like Oracle DB, are using hugetlbfs and explicitly disable
> THP. So unless THP can improve its performance to a level that is
> comparable to hugetlbfs, I won't see the later going away.

Yep, there are a few non-trivial workloads out there that flat out discourage
thp, ie: redis to avoid latency issues.

Thanks,
Davidlohr