<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 8, 2021 at 4:49 PM Alexander Yermolovich <<a href="mailto:ayermolo@fb.com">ayermolo@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Thanks for suggestions Artem.<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
Can you clarify on "<span style="color:rgb(0,0,0);font-family:verdana,sans-serif;font-size:15px;background-color:rgb(255,255,255);display:inline">You may be able to shuffle things around enough to avoid the issue for the time being,
 but it will not change the fact that the executable is too large and the overflow will come back sooner or later, as binaries tend to grow over time."<br>
</span><br>
As far as I can tell there is only one relocation from .text in to a cuda code. </div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">This is an implementation detail. There's no guarantee that it will be the case for everyone. It's just data. Nothing stops me from writing the code to access some GPU binaries directly. I believe some of the CUDA libraries do so.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">Some kind of cuda runtime. If the rest of the code is just GPU code, and .nv_fatbin is after .bss then seems like .nv_fatbin can continue to grow. </div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">It just happens to end up there as yet another data section. It is not expected to grow at runtime. AFAICT the GPU binaries are placed in a special section so various CUDA tools can find them. E.g. cuobjdump. Renaming the section or moving it around will not affect the functionality of the application itself.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">I guess .text and other sections
 can grow and eventually yes we will hit relocation overflows because of that.<br></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">It all will depend on the specifics of what gets linked into your executable.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">In general, if the sum total of your coda and data is more than 2GB, the possibility for the overflow is there. For an executable that large, it's impractical-to-impossible to guarantee that code X that accesses data Y are close enough. You can often do it in a specific case, but not in general. You do not control what ends up in .nv_fatbin and you do not have control over who/where/how accesses it. Moving fatbin to the top would move it out of the way of relocs between .text and regular data, but you're still open to overflows between the end of .text and .nv_fatbinary, if they are large enough.</div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">In other words, relocating GPU blobs to the top may provide a benefit, but it's not a complete solution. We've tried that already internally. One example -- it is not sufficient to avoid overflows in a tensorflow application with all needed CUDA libraries statically linked in.</div></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">BTW, I did attempt to move nv_fatbin upwards before. We've concluded that it wasn't worth it then: <a href="https://reviews.llvm.org/D47396">https://reviews.llvm.org/D47396</a></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">--Artem</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif"> </span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
Alex<br>
<br>
</div>
<div id="gmail-m_-4560078685188750808appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-4560078685188750808divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Artem Belevich <<a href="mailto:tra@google.com" target="_blank">tra@google.com</a>><br>
<b>Sent:</b> Wednesday, September 8, 2021 3:37 PM<br>
<b>To:</b> Wenlei He <<a href="mailto:wenlei@fb.com" target="_blank">wenlei@fb.com</a>><br>
<b>Cc:</b> Fāng-ruì Sòng <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>>; Alexander Yermolovich <<a href="mailto:ayermolo@fb.com" target="_blank">ayermolo@fb.com</a>>; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [llvm-dev] [LLD] Relocation overflows and .nv_fatbin</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">IMO, if your image has grown large enough to cause reloc overflows, rearranging location of GPU binaries or rearranging the objects inside of .nv_fatbin would only give you marginal benefits.
 You may be able to shuffle things around enough to avoid the issue for the time being, but it will not change the fact that the executable is too large and the overflow will come back sooner or later, as binaries tend to grow over time.</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">I would suggest considering reducing the executable size instead:</div>
<div style="font-family:verdana,sans-serif">* use nvprune to remove GPU binaries you do not need. CUDA libraries come with GPU binaries for all major GPU variants and that's a lot of GPU code. If you're only interested in one of those
 GPUs, Use nvprune to keep GPU blobs only for your GPU and that will reduce the executable size *a lot*.</div>
<div style="font-family:verdana,sans-serif">* Link with CUDA libraries dynamically. This also avoids the executable relocation issues, but adds runtime dependencies, which may be an issue in some cases.</div>
<div style="font-family:verdana,sans-serif">* If most of GPU code comes from the sources you compile yourself, then you can try enabling GPU image compression with <span style="font-variant-ligatures:none;margin:0px;padding:0px;box-sizing:border-box;color:rgb(0,136,0);font-family:monospace;font-size:14px;white-space:pre-wrap">-Xcuda-fatbinary
</span><span style="font-variant-ligatures:none;margin:0px;padding:0px;box-sizing:border-box;color:rgb(0,136,0);font-family:monospace;font-size:14px;white-space:pre-wrap">--<span style="margin:0px;padding:0px;box-sizing:border-box;font-weight:700;line-height:0">compress</span>-all
</span>This assumes you're compiling with clang, but I think NVCC sholud have a similar way to pass an option to fatbinary.</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">While neither of these workarounds solves the issue, they do tend to provide sufficient relief in most cases.</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">--Artem</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
</div>
<br>
<div>
<div dir="ltr">On Wed, Sep 8, 2021 at 2:44 PM Wenlei He via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p>> <span style="color:black">Reordering output sections is much more effective.</span><u></u><u></u></p>
<p><u></u> <u></u></p>
<p>If you have a huge .nv_fatbin, without moving input sections, you may end up with relocation at the beginning as well as at the end, then no matter where you put .nv_fatbin relative to .text (before or after), max relocation distance
 will grow when size of .nv_fatbin grows. <u></u><u></u></p>
<p><u></u> <u></u></p>
<p>So reordering output section alone isn’t enough. <u></u><u></u></p>
<p><u></u> <u></u></p>
<p>> Reordering input sections automatically has some small value but it<br>
> would break phase ordering and cause more maintenance burden.<u></u><u></u></p>
<p><u></u> <u></u></p>
<p>Could you elaborate on phase ordering?<u></u><u></u></p>
<p><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p style="margin-bottom:12pt"><b><span style="font-size:12pt;color:black">From:
</span></b><span style="font-size:12pt;color:black">llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Fāng-ruì Sòng via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Date: </b>Wednesday, September 8, 2021 at 1:19 PM<br>
<b>To: </b>Alexander Yermolovich <<a href="mailto:ayermolo@fb.com" target="_blank">ayermolo@fb.com</a>><br>
<b>Cc: </b><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject: </b>Re: [llvm-dev] [LLD] Relocation overflows and .nv_fatbin<u></u><u></u></span></p>
</div>
<div>
<p>On Wed, Sep 8, 2021 at 12:44 PM Alexander Yermolovich <<a href="mailto:ayermolo@fb.com" target="_blank">ayermolo@fb.com</a>> wrote:<br>
><br>
> Sorry I wasn't clear. I am not talking about moving .nv_fatbin in its entirety. Although we are also doing it with linker script INSERT AFTER .bss.<br>
> I was referring to re-arranging input sections within the .nv_fatbin output section.<br>
><br>
> So, we have in .text*<br>
> relocation into .nv_fatbin input section from foo3.o<br>
><br>
> In output .nv_fatbin without any changes we will have<br>
> foo1.o input section (some cuda code)<br>
> foo2.o input section (some cuda code)<br>
> foo3.o input section (has relocation in to)<br>
><br>
> With this layout we get relocation overflow.<br>
><br>
> if we shuffle things<br>
> foo3.o (has relocation in to from .text*)<br>
> foo1.o (some cuda code)<br>
> foo2.o (some cuda code)<br>
><br>
> It shortens the distance from src to dst fo relocation, and all other cuda sections can grow.<br>
><br>
> Hopefully, this clarifies things.<br>
> Alex<br>
><br>
<br>
Reordering output sections is much more effective.<br>
<br>
The ELF port has an option --symbol-ordering-file which reorders input<br>
sections within one output section, but I doubt you can find something<br>
as a marker.<br>
The option was originally conceived to improve performance (by<br>
optimizing for instruction cache/iTLB locality), not to mitigate<br>
relocation overflows.<br>
(macOS ld64 has a similar but more powerful -order_file which can<br>
specify input filenames.)<br>
<br>
Reordering input sections automatically has some small value but it<br>
would break phase ordering and cause more maintenance burden. So I<br>
very strongly object to that.<br>
<br>
><br>
><br>
><br>
><br>
> ________________________________<br>
> From: Fangrui Song <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>><br>
> Sent: Wednesday, September 8, 2021 12:01 PM<br>
> To: Alexander Yermolovich <<a href="mailto:ayermolo@fb.com" target="_blank">ayermolo@fb.com</a>><br>
> Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> Subject: Re: [llvm-dev] [LLD] Relocation overflows and .nv_fatbin<br>
><br>
> On 2021-09-08, Alexander Yermolovich via llvm-dev wrote:<br>
> >Hello<br>
> ><br>
> >I am seeing relocation overflows from .text section in to .nv_fatbin. The whole thing, nv_fatbin, is a bit of a black box, but there does appear to be only one. We have a downstream patch in LLD, that moves .nv_fatbin section(s) that have relocations in
 to to the "top". Looking around at what's in .nv_fartbin the rest of the code should be bunch of cuda stuff. So, in theory that can grow, and we shouldn't get any more relocation overflows. At least due to the size of .nv_fatbin.<br>
> ><br>
> >I was wondering if there is a better way of doing it. Maybe with a linker script? I investigated it, and that answer seems to be no, but I am not an expert in linker scripts.<br>
> ><br>
> >Thank You<br>
> >Alex<br>
><br>
> I implemented INSERT [AFTER|BEFORE] for orphan sections in <a href="https://reviews.llvm.org/D74375" target="_blank">https://reviews.llvm.org/D74375</a> <br>
> You may consider moving .nv* and __nv* sections after .bss<br>
><br>
> But linker synthesized etext/_etext may be in a weird position.<br>
> To fix that, use the OVERWRITE_SECTIONS feature I added for LLD 13.0.0<br>
><br>
> OVERWRITE_SECTIONS {<br>
>    .tdata : { etext = .; _etext = .; *(.tdata) }<br>
> }<br>
<br>
<br>
<br>
-- <br>
<span lang="ZH-CN" style="font-family:"PingFang SC",sans-serif">宋方睿</span><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
<u></u><u></u></p>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">--Artem Belevich</div>
</div>
</div>
</div>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">--Artem Belevich</div></div></div>