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
