Messages in this thread | | | Date | Mon, 10 Sep 2018 10:20:11 -0700 | From | Davidlohr Bueso <> | Subject | Re: Plumbers 2018 - Performance and Scalability Microconference |
| |
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
| |