On 08/08/2017 06:44 PM, Gil Tene wrote: > On Monday, August 7, 2017 at 11:50:27 AM UTC-7, Alen Vrečko wrote: > Saw this a while back. > > https://shipilev.net/jvm-anatomy-park/2-transparent-huge-pages/ > <https://shipilev.net/jvm-anatomy-park/2-transparent-huge-pages/> > > Basically using THP/defrag with madvise and using > -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch JVM opts. > > Looks like the defrag cost should be paid in full at startup due to > AlwaysPreTouch. Never got around to test this in production. Just have > THP disabled. Thoughts? > > The above flags would only cover the Java heap. In a Java application. So > obviously THP for non-Java > things doesn't get helped by that.
So, this is the reason why to use THP in "madvise" mode? Then JVM madvise-s Java heap to THP, upfront defrags it with AlwaysPreTouch, but native allocations stay outside of THP path, and thus do not incur defrag latencies. If there is a native structure that allocates with madvise hint and does heavy churn causing defrag, I'd say it should have not madvise in the first place. -Aleksey -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
