I can’t imagine the app has 34 mb of code in the hot path where this would matter - so I assume the application is partitioned with various Go routines doing a “type” of work.
Which encounters a problem with the Go design. You can’t partition Go routines, and you can’t set cpu/core affinity for a Go routine. So it can be very difficult to manage the cache (code & data) in a large multipurpose app, or an app where there data is naturally partitioned (e.g. a financial exchange where different stocks and asset classes are independent). I didn’t look but I believe there is a FR/issue to address the above deficiencies. > On Sep 18, 2021, at 8:26 PM, rmfr <remus.clearwa...@gmail.com> wrote: > > I have tried to disable the inline during compiling, but it results in no big > difference. > > On Saturday, September 18, 2021 at 9:26:45 PM UTC+8 ren...@ix.netcom.com > wrote: > I will add that over aggressive inlining can cause this - it explodes the > binary size. > > >> On Sep 18, 2021, at 7:37 AM, Jesper Louis Andersen <jesper.lou...@gmail.com >> <applewebdata://CCC69237-F973-4E2E-8E1E-20CE97269919>> wrote: >> > >> On Fri, Sep 17, 2021 at 11:09 AM rmfr <remus.cl...@gmail.com >> <applewebdata://CCC69237-F973-4E2E-8E1E-20CE97269919>> wrote: >> One of our Golang applications has a very huge binary size and the size of >> the .text segment itself in the elf is approximately 34MB. The iTLB load >> miss reaches about 87% of all iTLB cache hits. >> >> Is there any advice for big Golang applications to reduce the iTLB cache >> miss? Two solutions come to me, PGO >> <https://en.wikipedia.org/wiki/Profile-guided_optimization> and using >> hugepages to load the .text segment. But they are both seem very difficult >> to implement in Golang. >> >> >> >> Shot in the dark: is the application running next to some other application >> on the hardware which wipes the TLB? >> > >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com >> <applewebdata://CCC69237-F973-4E2E-8E1E-20CE97269919>. > >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiWDY%2Bjh2%3DPzAatJU5Ckit0_maex%3DgGC3E4M-t8VB94Qig%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAGrdgiWDY%2Bjh2%3DPzAatJU5Ckit0_maex%3DgGC3E4M-t8VB94Qig%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7de12443-2916-4190-a08d-0825605f6ca5n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/7de12443-2916-4190-a08d-0825605f6ca5n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/03F9275B-85F4-4E25-992A-108BFE01FA83%40ix.netcom.com.