|
@AndresFreundTec | |||||
|
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.
|
||||||
|
||||||
|
Andres Freund (Tech)
@AndresFreundTec
|
6. sij |
|
7.608 M/sec iTLB-loads w/ 50.80% iTLB-load-misses for normal mapping, vs 1.547 M/sec iTLB-loads w/ 48.82% iTLB-load-misses with text mapped as a huge page.
|
||
|
|
||
|
Andres Freund (Tech)
@AndresFreundTec
|
6. sij |
|
The magic necessary (linker flags to align the text sufficiently, link to libhugetlbfs, editing elf headers with hugeedit --text, setting up accessible hugetlbfs) seems too big for most, but I wonder if there's a way that could be simplified.
|
||
|
|
||
|
Andres Freund (Tech)
@AndresFreundTec
|
6. sij |
|
Oh, and besides being complicated: It currently also breaks perf profiles...
|
||
|
|
||
|
Thomas Munro
@MengTangmu
|
6. sij |
|
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").
twitter.com/MengTangmu/sta…
|
||
|
|
||
|
Andres Freund (Tech)
@AndresFreundTec
|
7. sij |
|
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.
|
||
|
|
||