Interesting. Doing the necessary rituals of sacrifice to get postgres started with the text segment mapped as huge pages yields nearly 10% speedup in a highly concurrent workload.
-
Show this thread
-
Replying to @AndresFreundTec
Thomas Munro Retweeted Thomas Munro
Nice.
#FreeBSD does this already (though admittedly I'd liek to have more control over whether it does it, which is more of an issue for DSM segments than the text segment, for eg parallel hash joins; on Linux the answer there is also "never").https://twitter.com/MengTangmu/status/1135003656032587776 …Thomas Munro added,
Thomas Munro @MengTangmuI heard a claim that some DB goes up to ~6% faster in some benchmark when the code is mapped with huge pages, on Linux, which (for now) requires special linking and a hugectl wrapper to remap. But#PostgreSQL text segment is automagically in super pages on my#FreeBSD box. Woo!1 reply 2 retweets 1 like -
Replying to @MengTangmu
It does? For it to work well one needs to make sure that the text segment and data/bss segments are far enough apart to fit onto separate 2MB huge pages. Otherwise you'd give up sharing the text segment, which'd again have its own cost.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
Hmm, recent research on making it work well, using PostgreSQL (and other stuff): https://www.cs.rochester.edu/u/xdong/ispass-19-final.pdf …
1 reply 0 retweets 1 like -
Replying to @MengTangmu
Thats quite interesting. They note that " Extending the residual code mapping to the end ofa superpage is made possible because the data segment isseparated from the code by 2MB of unused virtual addressspace (TableV)." - which isn't the case when compiling here locally...
1 reply 0 retweets 0 likes
I just forced the linkers hand to have it align segments to huge boundaries, but that's obviously not a real solution (makes the binary a lot bigger).
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.