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 


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 mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to